[llvm-dev] RFC: On non 8-bit bytes and the target for it

[James Molloy via llvm-dev]

Hi Chris,

SelectionDAGBuilder, DAGCombine and anything in CodeGen (but I can't think
of any examples there offhand, come to think of it). I must admit that
until I wrote up that email, it hadn't quite occurred to me how much of the
change would be testable. After the writeup, it doesn't sounds quite as
contentious as I considered it.

SelectionDAGBuilder is a simple non-invasive change to
visitGetElementPtrInst(); DAGCombiner may have some nasties lurking in it.
Inability to test a DAGCombine is hardly a new problem though :)

Cheers,

James

On Tue, 5 Nov 2019 at 21:52, Chris Lattner <clattner at nondot.org> wrote:

> On Nov 4, 2019, at 4:00 PM, James Molloy via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> > We'd be keen to help out what the community decides to do here. I
> personally feel it's reasonable that:
> >   - LangRef/DataLayout is updated with semantically coherent changes.
> >   - The midend optimizer is updated by someone who cares about those
> changes and tests are added that use the new DataLayout.
>
> This makes perfect sense to me - if you want the mid-level optimizer to be
> aware of this, then it makes sense for it to be part of DataLayout.
>
> Question though: given that approach, wouldn’t that make this whole thing
> in-tree-testable?
>
> What would not be testable given the appropriate data layout extensions?
>
> -Chris
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191106/6660d62d/attachment.html>