i1 vectors (Re: [PATCH] Fix PR15267)

[Hal Finkel]

----- Original Message -----
> From: "Duncan Sands" <baldrick at free.fr>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: llvm-commits at cs.uiuc.edu, "Nadav Rotem" <nrotem at apple.com>
> Sent: Wednesday, February 20, 2013 11:38:45 AM
> Subject: Re: [PATCH] Fix PR15267
> 
> Hi Hal,
> 
> >>>> it sounds like you consider <4 x i1> to be bitpacked in memory,
> >>>> like i4.
> >>>> Is that right?
> >>>
> >>> Yes. We need this in order to be consistent with targets that
> >>> support mask
> >>> registers.
> >>
> >> while it makes sense to me, can you please document this somewhere
> >> and ensure
> >> that getTypeAllocSize and friends are fixed (should return 1
> >> byte!).
> >
> > Also, we need to make sure that global constants are emitted
> > correctly. Currently, if you make a <N x i1> global constant, it
> > will emit each element into a separate byte.
> 
> all kinds of codegen stuff is broken for these types.  However even
> before
> getting as far as codegen, there are issues at the IR level (type
> sizes as
> I mentioned, and also passes that get it wrong for these types).
>  Someone
> really needs to audit the IR carefully (I would volunteer but I don't
> think
> I have time), and then take a careful look at codegen (particularly
> the type
> legalization logic; I'm probably the right guy to do that, but...).

To bring this up again, I'm becoming increasingly nervous, seeing all of the i1 vector support, not only in AVX but also in AVX-512, going into the x86 backend while this has not yet been addressed.

I think that either we should come up with a definitive plan for dealing with this, or we should forbid outright the loading/storing of i1 vectors until we do. The in-register representations of the i1 vectors, as far as I can tell, is fine (so long as the backend provides a self-consistent implementation of build_vector, extract_elemt, etc.). However, providing i1 vectors in their current state, as part of the general LLVM IR interface, with an exposed yet inconsistent memory representation, feels like asking for trouble.

 -Hal

> 
> Ciao, Duncan.
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory