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

[Ryan Taylor]

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>