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 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
