[llvm-dev] RFC: On non 8-bit bytes and the target for it
James Molloy via llvm-dev
llvm-dev at lists.llvm.org
Wed Nov 6 07:43:35 PST 2019
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 :)
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
> What would not be testable given the appropriate data layout extensions?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev