search for: r112696

...c vectors onto MMX operations. This will define away the existing -disable-mmx flag and make stuff like this impossible. > > However, this isn't going to happen in the next couple days, certainly not in time for the 2.8 release branch on friday. As such, I checked in a horrible hack in r112696 that prevents SRoA from introducing mmx specific vector types. I'm not aware of a target where those datatypes are actually useful, so this shouldn't be bad. On your testcase, no mmx operations are produced. Those types are all used with NEON. I'll try to do some experiments to meas...

...ing generic vectors onto MMX operations. This will define away the existing -disable-mmx flag and make stuff like this impossible. However, this isn't going to happen in the next couple days, certainly not in time for the 2.8 release branch on friday. As such, I checked in a horrible hack in r112696 that prevents SRoA from introducing mmx specific vector types. I'm not aware of a target where those datatypes are actually useful, so this shouldn't be bad. On your testcase, no mmx operations are produced. Please let me know if you see any other MMX stuff being generated. -Chris

...s onto MMX operations. This will define away the existing -disable-mmx flag and make stuff like this impossible. >> >> However, this isn't going to happen in the next couple days, certainly not in time for the 2.8 release branch on friday. As such, I checked in a horrible hack in r112696 that prevents SRoA from introducing mmx specific vector types. I'm not aware of a target where those datatypes are actually useful, so this shouldn't be bad. On your testcase, no mmx operations are produced. > > Those types are all used with NEON. I'll try to do some experimen...

...are incorrectly generated. That said, the work isn't > finished, so it shouldn't be in 2.8. In 2.9, the only way to get MMX will be to use mmx intrinsics, generic vectors will not map onto MMX, sorry Nicolas. One major problem is that the optimizer introduces generic vectors (e.g. see r112696 in the SRoA pass) which use mmx where it was not previously used. This means that your frontend introducing emms is not enough. -Chris

Hi, I've attached 2 .ll files which are supposed to be equivalent but 'unopt-fail.ll' causes a crash in webkit's test suite while 'unopt-pass.ll' does not. I can't give more details about the crash, when I run the crashing test it in isolation it passes, when I run the full suite it crashes; it boggles the mind. Below I provide the optimized asm that is produced from

...MX operations. This will define away the existing -disable-mmx flag and make stuff like this impossible. >>> >>> However, this isn't going to happen in the next couple days, certainly not in time for the 2.8 release branch on friday. As such, I checked in a horrible hack in r112696 that prevents SRoA from introducing mmx specific vector types. I'm not aware of a target where those datatypes are actually useful, so this shouldn't be bad. On your testcase, no mmx operations are produced. >> >> Those types are all used with NEON. I'll try to do some e...

On Wed, Sep 8, 2010 at 12:35 AM, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi Chris, > > It's not broken, but the performance is crippled. > > I noticed that the code still contains some MMX instructions, but several > operations get expanded (apparently swizzling and such get expanded to a > large number of byte moves). I think some changes related to