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

[Ahmed Bougacha]

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