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

[Ryan Taylor]

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/20080532/attachment.html>