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

Eli Friedman eli.friedman at gmail.com
Wed Jul 8 01:49:35 PDT 2009


On Wed, Jul 8, 2009 at 1:08 AM, Duncan Sands<baldrick at free.fr> wrote:
> Hi Dan,
>
>> %y has type <4 x i1>. This is not a legal type on most current
>> architectures. But, many architectures have ways of supporting
>> this kind of code, often by putting the comparison result in a
>> <4 x i32> register.
>>
>> The main twist is that a type like <4 x i1> might be legalized
>> to either <4 x i32> or <4 x i64> on a target like x86, depending
>> on the type of the comparison operands, so the current
>> getTypeToTransformTo, which assumes that every type has a
>> unique destination type, isn't sufficient.
>
> I think this is a misunderstanding of the roles of type and
> operation legalization.  The getTypeToTransformTo method exists
> entirely for the benefit of type legalization.  Since <4 x i1> is
> an illegal type, it needs to be transformed into the legal type
> given by getTypeToTransformTo, for example <4 x i8>.

We don't support that kind of promotion at the moment, although I
suppose that's an implementation detail rather than a fundamental
issue.

> After type
> legalization has finished you will have vector comparison operations
> returning <4 x i8>.  Now operation legalization kicks in.  Since the
> target machine cannot handle vector comparisons returning <4 x i8>,
> operation legalization needs to turn that into a comparison returning
> <4 x i32> or <4 x i64>.  It of course needs some way to know which
> type to use, but this has nothing to do with getTypeToTransformTo.

Well, suppose a comparison of two <4 x i32> vectors.  Your natural
promotion for the result on x86 would be to a <4 x i16>.  But yes, you
could put off the subsequent adjustments to operation legalization,
although if it weren't custom-lowered, it would likely end up
producing something really ugly.

-Eli




More information about the llvm-commits mailing list