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