<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 16, 2019 at 1:09 PM Roman Lebedev via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">FWIW I'm personally cautiously non-optimistic about this,<br>
but maybe i'm just not seeing the whole picture of the proposal.<br>
<br>
Both checking final asm, and checking more than one layer of abstraction<br>
feels overreaching and very prone to breakage/too restrictful.<br>
Even minimal changes to the scheduling for particular CPU can cause many<br>
instructions to reorder.<br>
I'm not sure what effect that will have on middle-end pass development, too.<br>
<br>
A change affects these end-to-end tests, what then?<br>
Just blindly regenerate every affected test?<br>
This will be further complicated once clang isn't the only upstream front-end.<br></blockquote><div><br>Agreed that the broader a test is, the more careful one has to be about making it reliable in spite of other changes - sometimes that's really difficult (if you're trying to get a particular instruction selection or register allocation) but in others it can be fairly reliable if done carefully to sufficiently restrict optimizations, etc. (having function calls to external functions to act as sinks/sources for values, etc, for instance - picking places where the output is already "optimal" and trivially/obviously so (for whatever set of constraints you've provided - not heroic optimizations, etc) to ensure that it's fairly stable)<br><br><br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Roman.<br>
<br>
On Wed, Oct 16, 2019 at 11:00 PM David Greene via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Renato Golin via Openmp-dev <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>> writes:<br>
><br>
> > We already have tests in clang that check for diagnostics, IR and<br>
> > other things. Expanding those can handle 99.9% of what Clang could<br>
> > possibly do without descending into assembly.<br>
><br>
> I agree that for a great many things this is sufficient.<br>
><br>
> > Assembly errors are more complicated than just "not generating VADD",<br>
> > and that's easier done in the TS than LIT.<br>
><br>
> Can you elaborate?  I'm talking about very small tests targeted to<br>
> generate a specific instruction or small number of instructions.<br>
> Vectorization isn't the best example.  Something like verifying FMA<br>
> generation is a better example.<br>
><br>
>                         -David<br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>