> On Aug 25, 2014, at 4:43 PM, Quentin Colombet <[email protected]> wrote: > > Thanks Bob for the context. > > On Aug 25, 2014, at 4:05 PM, Bob Wilson <[email protected] > <mailto:[email protected]>> wrote: > >> + Jim Grosbach >> >>> On Aug 25, 2014, at 10:45 AM, Quentin Colombet <[email protected]> wrote: >>> >>> Thanks Renato. >>> >>> I’ll wait for Bob’s inputs but I think, like you, removing the optimization >>> level is the right thing to do. >>> >>> -Quentin >> >> This is kind of an unusual test that doesn’t fit the usual mold. I’m >> hesitant to defend it, except to say that so far, it is better than the >> alternatives. >> >> Jim and I have debated this at some length, and Jim agrees with both of you >> that the “right” thing to do is to have a front-end test that checks the IR >> output of the front-end, with separate tests in the backend to check that >> the IR is translated to the expected assembly. >> >> We don’t have that. >> >> We have backend tests for some Neon code-gen and perhaps a few front-end >> tests for intrinsics as well, but there are a huge number of Neon intrinsics >> and it is important to have exhaustive tests for all of them. That’s what >> this test is for. It is machine-generated from clang’s arm_neon.td file. >> Obviously, if someone introduces a bug in the .td file, we would not catch >> it with this test. To avoid that, we have checked-in this pre-generated >> test, which we have manually checked against ARM’s documentation of the Neon >> intrinsics. I had requested an automatic test to regenerate it and check for >> differences, but I’m not sure that has gotten implemented yet. >> >> So, anyway, that is the context. The reason it is compiled with optimization >> is that the auto-generated checks need to look for certain opcodes and >> without optimization, you won’t get many of them. > > What do you recommend for the test cases where we are able to optimize the > sequence of instructions? (See my examples form a previous mail)
Well, as you can see, we just omit the checks. There weren’t a lot of other options when we were auto generating the tests from very limited info in the arm_neon.td file. I should also point out that when James Molloy rewrote the TableGen Neon intrinsic emitter in r211101, he removed all the testcase generation. I don’t know the status of putting it back. James, is that something that even makes sense to do now? > Since we have to run with the optimizations enabled, is it worth reworking > the test cases to use the values produced by the copy-related intrinsics? > That way the moves wouldn’t be coalesced. I suppose. Since we no longer have the automatic test generation, maybe we should just use the existing test as a starting point and go ahead and make incremental improvements to it. I’m not opposed to that, anyway. > > Thanks, > -Quentin > >> >>> On Aug 25, 2014, at 10:31 AM, Renato Golin <[email protected]> wrote: >>> >>>> On 25 August 2014 17:57, Quentin Colombet <[email protected]> wrote: >>>>> The problem is that the intrinsics at stake are just fancy moves, that can >>>>> be coalesced. I do not think there is a way to prevent the optimization to >>>>> happen other than disabling the optimization. >>>> >>>> Well, those intrinsics are useful for a few things, normally a >>>> sequence of neon calls to which the move is not clear and needs to be >>>> explicit. Although this case was obvious and "easy" to generate, it's >>>> normally the first optimizations you end up doing, so not stable >>>> enough. >>>> >>>> >>>>> I can add the flag to do that, but I guess that wouldn’t be the right fix, >>>>> since we could have another backend that LLVM. >>>>> If we do want to check the lowering of intrinsics, shouldn’t we drop Os >>>>> from >>>>> the run command? >>>> >>>> Yes! We want to test if the front-end is generating the correct >>>> intrinsic, so any level of optimization will hide whatever we were >>>> trying to test in the first place. I risk to say that whomever removed >>>> the other tests in this file also did wrong, and we need to fix this. >>>> >>>> I'm copying Bob since he was the one writing the NEON intrinsics in >>>> the first place, maybe he can see things I fail to. But AFAICS, >>>> disabling *any* optimization and re-checking for the correct >>>> instructions is the way to go. >>>> >>>> cheers, >>>> --renato
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
