r216249 - [test/CodeGen/ARM] Adpat test to match new codegen after r216236.

[Bob Wilson]

> On Aug 26, 2014, at 7:04 AM, Renato Golin <renato.golin at linaro.org> wrote:
> 
> On 26 August 2014 14:58, James Molloy <james at jamesmolloy.co.uk> 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.