Matthias Braun
2015-Apr-21 04:21 UTC
[LLVMdev] Why are imm shifts where imm >= width type eliminated entirely?
There can also be other “problems" like this one: http://reviews.llvm.org/D6946 <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/20150420/483bba97/attachment.html>
Ryan Taylor
2015-Apr-28 15:02 UTC
[LLVMdev] Why are imm shifts where imm >= width type eliminated entirely?
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>
Ryan Taylor
2015-Apr-28 17:39 UTC
[LLVMdev] Why are imm shifts where imm >= width type eliminated entirely?
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>