[LLVMdev] Why are imm shifts where imm >= width type eliminated entirely?

[Ryan Taylor]

I have yet to see an example of how one would write a zero extended imm
using ImmLeaf?

Thanks.

On Tue, Apr 28, 2015 at 11:02 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:

> So when I use a PatLeaf in 'shl' as an immediate such as:
>
> def immZExt16 : PatLeaf<(imm), [{return isInt<16>)(N->getZExtValue());}]>;
>
> I get 'could not infer all types' for 'shl' with imm and an assert
> 'isConcrete() && "Type isn't concrete yet"
>
> Why does the type have to be concrete for shl? I'm obviously not getting
> this error for any other operations, such as add, sub, mul, div, divrem,
> etc... who all use the same super multiclass.
>
> I'm trying to fit all 3 op alu instructions into two sub-multiclasses
> (commutative and non commutative, because LLVM makes the imm the rhs for
> commutative ops, you can't just do one multiclass for both without getting
> warnings/errors). It would make sense that shl would be able to fit into
> this multiclass (which takes PatLeaf for the imm as above).
>
> Thanks.
>
> On Tue, Apr 21, 2015 at 12:21 AM, Matthias Braun <matze at braunis.de> wrote:
>
>> There can also be other “problems" like this one:
>> http://reviews.llvm.org/D6946
>>
>> - Matthias
>>
>> On Apr 20, 2015, at 1:44 PM, Tim Northover <t.p.northover at gmail.com>
>> wrote:
>>
>> The DAG combiner also performs the undefined shift -> undef though, so it
>> should still be OK
>>
>>
>> DAG combiner doesn't really run to convergence as far as I'm aware, so
>> you often get extremely difficult to test but necessary checks like
>> this.
>>
>> Tim.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150428/b30ccf97/attachment.html>