[llvm-commits] PATCH: remove VICmp and VFCmp.

[Eli Friedman]

On Thu, Jul 9, 2009 at 1:27 PM, Duncan Sands<baldrick at free.fr> wrote:
> David Greene wrote:
>> On Thursday 09 July 2009 13:20, Chris Lattner wrote:
>>>> Storing an <8 x i1> to memory with the same layout as [8 x i1] -- as
>>>> 8 bytes -- has the nice property of being friendly to various LLVM
>>>> assumptions. Unfortunately, it's also highly artificial; existing
>>>> vector hardware I'm familiar with doesn't work that way, and it
>>>> seems unlikely that anyone ever would want it to. However, it might
>>>> be ok for LLVM to define <8 x i1> stores this way for consistency
>>>> and then tell everyone to avoid using them.
>>
>> So what's the alternative?  Bitcast to i8 and then store?
>
> I don't think bitcasting to i8 will be possible: lots of places
> "know" that bitcast is the same as "store as first type, load
> as the other".  If <8 x i1> doesn't store like i8 then allowing
> bitcast would break this invariant.  I don't think that's wise.

Mmm, right... that's nasty.  But we also can't just make bitcasting
to/from vector types illegal; a lot of existing code depends on that.
Only allowing bitcasts for vectors of power-of-two byte-sized types is
possible, but it will make the code depending on the
store+load->bitcast invariant break anyway.  The only way to preserve
that invariant would be to bit-pack vectors in memory, and Chris
already rejected that option.

That said, how much code actually expects that invariant?  Off the top
of my head, I can only come up with legalization for bitcasts,
scalarrepl, and maybe some bits of instcombine.

-Eli