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

[Chris Lattner via llvm-dev]

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>