[LLVMdev] ReduceLoadWidth, DAGCombiner and non 8bit loads/extloads question.

[Patrik Hägglund H]

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>