llvm dev - Mar 2015 - [LLVMdev] ReduceLoadWidth, DAGCombiner and non 8bit loads/extloads question.

On Thu, Mar 5, 2015 at 4:19 PM, Ryan Taylor <ryta1203 at gmail.com>
wrote:
> Thanks for the reply:
>
> So should LLVM continue to assume 8-bit byte addressing? It would be nice,
> not only to us but potential future machines, to have a permanent fix to
> this assumption? This sounds reasonable yes?
>
> Marking them as Custom in XXXISelLowering still produces error, the
> pre-legalize phase is still going to opt to LD1 since it's not caring
about
> target-specifics. Then, again, we'll be stuck trying to undo the
addressing.
>
> I see what you mean about the DAGCombiner, that's a two part solution,
first
> turning them into target-specific before any opts in pre-legalize and then
> back before any opts in post-legalize. Certainly a potential solution,
> though we may lose some optimization opportunities, even on valid loads, as
> you mention.
>
> The ultimate issue here, for us, is that LLVM makes the assumption that
> every machine is going to support 8-bit byte-addressing. I'm not sure
this
> is a solid or even reasonable assumption going forward?
Short version: Patches welcome ;)   Long version: in general, if
something is not supported yet, it means no one needed it, so no one
put the work into it.  If you're willing to do so, I'd approve of
fixing the various parts that assume this (if it's only DAGCombines
that's fine).  Then there's the problem of how to test this in-tree
when no in-tree target has these problems (Krzysztof mentions Hexagon,
do you both have the same problem?).  But that's another conversation!
> Possibly, we could just pseudo support it and expand it later, but the
> addressing would still be an issue, I believe.
You might want to look into MachineMemOperands, which tracks the
memory object a load/store points into.  It could help with the
expansion.

-Ahmed

Ahmed,

  Ok, thanks. I'm not sure at this point the extend of LLVM's dependence
on
the requirement of 8-bit byte-addressing and how extensive that patch would
have to be.

  If we made the changes, we would keep it local to us until at which time
we could add our target, I would presume anyways, though that's not exactly
my call, though even so I would think the more important issue for testing
in-tree would be to make sure it didn't break any existing tests on
existing targets but yes, that too. :)

Thanks again.

On Fri, Mar 6, 2015 at 1:18 PM, Ahmed Bougacha <ahmed.bougacha at
gmail.com>
wrote:
> On Thu, Mar 5, 2015 at 4:19 PM, Ryan Taylor <ryta1203 at gmail.com>
wrote:
> > Thanks for the reply:
> >
> > So should LLVM continue to assume 8-bit byte addressing? It would be
> nice,
> > not only to us but potential future machines, to have a permanent fix
to
> > this assumption? This sounds reasonable yes?
> >
> > Marking them as Custom in XXXISelLowering still produces error, the
> > pre-legalize phase is still going to opt to LD1 since it's not
caring
> about
> > target-specifics. Then, again, we'll be stuck trying to undo the
> addressing.
> >
> > I see what you mean about the DAGCombiner, that's a two part
solution,
> first
> > turning them into target-specific before any opts in pre-legalize and
> then
> > back before any opts in post-legalize. Certainly a potential solution,
> > though we may lose some optimization opportunities, even on valid
loads,
> as
> > you mention.
> >
> > The ultimate issue here, for us, is that LLVM makes the assumption
that
> > every machine is going to support 8-bit byte-addressing. I'm not
sure
> this
> > is a solid or even reasonable assumption going forward?
>
> Short version: Patches welcome ;)   Long version: in general, if
> something is not supported yet, it means no one needed it, so no one
> put the work into it.  If you're willing to do so, I'd approve of
> fixing the various parts that assume this (if it's only DAGCombines
> that's fine).  Then there's the problem of how to test this in-tree
> when no in-tree target has these problems (Krzysztof mentions Hexagon,
> do you both have the same problem?).  But that's another conversation!
>
> > Possibly, we could just pseudo support it and expand it later, but the
> > addressing would still be an issue, I believe.
>
> You might want to look into MachineMemOperands, which tracks the
> memory object a load/store points into.  It could help with the
> expansion.
>
> -Ahmed
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150306/e90cdb0f/attachment.html>

Hi Ryan,

We maintain internally a number of patches (towards trunk) to support 16-bit
bytes in LLVM (not Clang). I can provide them upon request. Disclaimer: They
work for us. Some are good, others ugly or incomplete.

/Patrik Hägglund

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Ryan Taylor
Sent: den 6 mars 2015 22:41
To: Ahmed Bougacha
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] ReduceLoadWidth, DAGCombiner and non 8bit loads/extloads
question.

Ahmed,

  Ok, thanks. I'm not sure at this point the extend of LLVM's dependence
on the requirement of 8-bit byte-addressing and how extensive that patch would
have to be.

  If we made the changes, we would keep it local to us until at which time we
could add our target, I would presume anyways, though that's not exactly my
call, though even so I would think the more important issue for testing in-tree
would be to make sure it didn't break any existing tests on existing targets
but yes, that too. :)

Thanks again.

On Fri, Mar 6, 2015 at 1:18 PM, Ahmed Bougacha <ahmed.bougacha at
gmail.com<mailto:ahmed.bougacha at gmail.com>> wrote:
On Thu, Mar 5, 2015 at 4:19 PM, Ryan Taylor <ryta1203 at
gmail.com<mailto:ryta1203 at gmail.com>> wrote:
> Thanks for the reply:
>
> So should LLVM continue to assume 8-bit byte addressing? It would be nice,
> not only to us but potential future machines, to have a permanent fix to
> this assumption? This sounds reasonable yes?
>
> Marking them as Custom in XXXISelLowering still produces error, the
> pre-legalize phase is still going to opt to LD1 since it's not caring
about
> target-specifics. Then, again, we'll be stuck trying to undo the
addressing.
>
> I see what you mean about the DAGCombiner, that's a two part solution,
first
> turning them into target-specific before any opts in pre-legalize and then
> back before any opts in post-legalize. Certainly a potential solution,
> though we may lose some optimization opportunities, even on valid loads, as
> you mention.
>
> The ultimate issue here, for us, is that LLVM makes the assumption that
> every machine is going to support 8-bit byte-addressing. I'm not sure
this
> is a solid or even reasonable assumption going forward?
Short version: Patches welcome ;)   Long version: in general, if
something is not supported yet, it means no one needed it, so no one
put the work into it.  If you're willing to do so, I'd approve of
fixing the various parts that assume this (if it's only DAGCombines
that's fine).  Then there's the problem of how to test this in-tree
when no in-tree target has these problems (Krzysztof mentions Hexagon,
do you both have the same problem?).  But that's another conversation!
> Possibly, we could just pseudo support it and expand it later, but the
> addressing would still be an issue, I believe.
You might want to look into MachineMemOperands, which tracks the
memory object a load/store points into.  It could help with the
expansion.

-Ahmed

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150309/2381fd30/attachment.html>