llvm dev - Nov 2019 - RFC: On non 8-bit bytes and the target for it

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

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>

On Nov 6, 2019, at 7:43 AM, James Molloy <james at jamesmolloy.co.uk>
wrote:
> 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 :)
Yeah, that was my sense.  Here is another crazy question - just to probe the
limits of your tolerance here :-).

Assuming we added a new field to DataLayout, what would the emergent behavior be
for an “invalid" configuration given a target?

Let me consider an existing situation: what would happen if we shoved a .ll file
with a datalayout specifying ‘big endian’ into X86 or some other little endian
target?

The answer (assuming no hard error) is that all the target independent logic
would still key off of this, and the target specific logic wouldn’t.  Given that
the testing goal is to generalize the target independent logic and test it, this
emergent behavior may be enough to test the (e.g.) SelectionDAGBuilder changes
with some existing target.

-Chris

> 
> Cheers,
> 
> James
> 
> On Tue, 5 Nov 2019 at 21:52, Chris Lattner <clattner at nondot.org
<mailto:clattner at nondot.org>> wrote:
> On Nov 4, 2019, at 4:00 PM, James Molloy via llvm-dev <llvm-dev at
lists.llvm.org <mailto: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/cd7d02ac/attachment.html>