llvm dev - Jul 2011 - [LLVMdev] Custom lowering of load with extension

Hi,

The target I am working on does not support i8 loading: it supports only 32
bit aligned loads.
I had to custom lower i8 load so that only i32 loads are generated.

My issue is the following:
In a very specific case, the lowering stage generates the following pattern
where the load is a i32 load:
(and (load x), 255)
This pattern is somehow converted by the DAG combiner back to:
 (zextload x, i8)
And then, during the instruction selection phase, I get:
error in backend: Cannot select: 0xb3a5558: i32,ch = load 0xb3823c4,
0xb3a1890, 0xb3a2440<LD1[%4](align=4), zext from i8>
because the instruction is simply not supported by the backend (that's the
initial reason for implementing the custom lowering !)

How come the DAG combiner converts my lowering back to an i8 loading ?
Looking at the DAGCombiner.cpp code, this transformation is done because
isLoadExtLegal returns true in the case of custom lowering of load which
does not seem logical to me (do you have an explanation for this ?).

Well, I assume I didn't do sth the right way... Can you point a mistake in
my reasoning ?

  Thank you !

  Damien
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110718/115477c0/attachment.html>

On Mon, Jul 18, 2011 at 6:35 PM, Damien Vincent <damien.llvm at gmail.com>
wrote:
>
>   Hi,
>
> The target I am working on does not support i8 loading: it supports only 32
> bit aligned loads.
> I had to custom lower i8 load so that only i32 loads are generated.
>
> My issue is the following:
> In a very specific case, the lowering stage generates the following pattern
> where the load is a i32 load:
> (and (load x), 255)
> This pattern is somehow converted by the DAG combiner back to:
>  (zextload x, i8)
> And then, during the instruction selection phase, I get:
> error in backend: Cannot select: 0xb3a5558: i32,ch = load 0xb3823c4,
> 0xb3a1890, 0xb3a2440<LD1[%4](align=4), zext from i8>
> because the instruction is simply not supported by the backend (that's
the
> initial reason for implementing the custom lowering !)
>
> How come the DAG combiner converts my lowering back to an i8 loading ?
> Looking at the DAGCombiner.cpp code, this transformation is done because
> isLoadExtLegal returns true in the case of custom lowering of load which
> does not seem logical to me (do you have an explanation for this ?).
>
> Well, I assume I didn't do sth the right way... Can you point a mistake
in
> my reasoning ?
Looks like a bug to me too. :)  r135462 should fix it.

-Eli

Thank you Eli, it seems to fix my bug.

  Damien

On Mon, Jul 18, 2011 at 7:25 PM, Eli Friedman <eli.friedman at
gmail.com>wrote:
> On Mon, Jul 18, 2011 at 6:35 PM, Damien Vincent <damien.llvm at
gmail.com>
> wrote:
> >
> >   Hi,
> >
> > The target I am working on does not support i8 loading: it supports
only
> 32
> > bit aligned loads.
> > I had to custom lower i8 load so that only i32 loads are generated.
> >
> > My issue is the following:
> > In a very specific case, the lowering stage generates the following
> pattern
> > where the load is a i32 load:
> > (and (load x), 255)
> > This pattern is somehow converted by the DAG combiner back to:
> >  (zextload x, i8)
> > And then, during the instruction selection phase, I get:
> > error in backend: Cannot select: 0xb3a5558: i32,ch = load 0xb3823c4,
> > 0xb3a1890, 0xb3a2440<LD1[%4](align=4), zext from i8>
> > because the instruction is simply not supported by the backend
(that's
> the
> > initial reason for implementing the custom lowering !)
> >
> > How come the DAG combiner converts my lowering back to an i8 loading ?
> > Looking at the DAGCombiner.cpp code, this transformation is done
because
> > isLoadExtLegal returns true in the case of custom lowering of load
which
> > does not seem logical to me (do you have an explanation for this ?).
> >
> > Well, I assume I didn't do sth the right way... Can you point a
mistake
> in
> > my reasoning ?
>
> Looks like a bug to me too. :)  r135462 should fix it.
>
> -Eli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110719/aa23d50d/attachment.html>