> On Aug 26, 2014, at 7:04 AM, Renato Golin <[email protected]> wrote: > > On 26 August 2014 14:58, James Molloy <[email protected]> wrote: >> But what value do these derived tests have? In order to change the code the >> intrinsics produce (i.e. break them), you need to touch arm_neon.td. But >> arm_neon.td would also be the generation source for these tests. So you have >> a tautological testing mechanism. > > Good point. > > Maybe we could use a standard base as the source, something produced > by ARM, that could even later be manually curated, since I don't > expect it to change dramatically over the next decades.
You’re only focusing on one side of this test. As it currently stands, it is a test for both the front-end and back-end implementation. You can easily break it without touching arm_neon.td by changing Neon code-gen in the back-end. Like I said earlier, ideally it would be nice to have separate comprehensive tests in both the front-end and back-end, but until we get that, this is better than nothing, and there are actually some advantages in having end-to-end testing like this. Since we have already manually checked this test against ARM’s documentation, I don’t have a strong opinion about bringing back the automatic test generation feature in TableGen. Manually updating this test for any changes that apply to a large fraction of the intrinsics would be a major headache, but hopefully we won’t need anything like that now. Also, in reply to Renato’s comment earlier in this thread about checking the clang-generated IR for calls to builtins, I’d like to point out that many of these intrinsics do not translate to builtins and even more of them use a combination of builtins and other IR operations. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
