Hi Renato, I think there are two tests that can be derived from here, and maybe > both of them can be easily done on their own, depending on how Clang > lowers its intrinsics.
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. Cheers, James On 26 August 2014 09:56, Renato Golin <[email protected]> wrote: > On 26 August 2014 08:24, James Molloy <[email protected]> wrote: > > I can see that test had to be originally generated somehow, but now we > have > > it and we don't expect large churn in the intrinsics, does it make sense > to > > reimplement the autogeneration mechanism? I haven't worked at all on > getting > > it put back in the new framework, but if people think it's the right > thing > > to do I can make time to do so. I'm just not convinced that it has value. > > Hi James, > > I think there are two tests that can be derived from here, and maybe > both of them can be easily done on their own, depending on how Clang > lowers its intrinsics. > > The first, Clang based test, is more or less what that one is, but > instead of checking for asm instructions, it emits IR and checks for > the correct builtin call. I should hope that no ARM-specific > optimization has occurred by that time. The second, a list of IR > one-liners with the intrinsics generated by Clang (well, any > front-end), and their unoptimized correspondents. > > To make sure we don't lose intrinsics by updating one and not the > other, we should have a script in tree (utils) that generates them, > possibly based on some other source in tree (table gen), for both > Clang and LLVM counterparts. > > Having said that, I don't think this project is particularly critical > to our test infrastructure, so I'd give this to a summer student this > year or a GSoC project the next. > > cheers, > --renato >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
