I committed a change to fix pr4731 yesterday but after thinking about it some more, I'd like to get other opinions about this. Chris and I talked last week about the need to canonicalize the types used for Neon vector shuffles so that they get CSEd. I guess this was an issue that came up for SSE. For pr4731, I changed llvm-gcc to canonicalize a bitwise vector operation to use i32 elements. For these operations, the type doesn't matter since the vector are treated as a bunch of bits. I was thinking that we should do the canonicalization for all the bitwise vector operations. But is llvm-gcc the right place to do that? The changes that I discussed with Chris were in code gen. It seems like the front-end is not the best place to do that kind of optimization and that ideally the optimizer would be able to recognize that bitwise vector operations do not depend on the element type. Opinions?
On Aug 17, 2009, at 7:15 AM, Bob Wilson wrote:> I committed a change to fix pr4731 yesterday but after thinking about > it some more, I'd like to get other opinions about this. Chris and I > talked last week about the need to canonicalize the types used for > Neon vector shuffles so that they get CSEd. I guess this was an issue > that came up for SSE. > > For pr4731, I changed llvm-gcc to canonicalize a bitwise vector > operation to use i32 elements. For these operations, the type doesn't > matter since the vector are treated as a bunch of bits. I was > thinking that we should do the canonicalization for all the bitwise > vector operations. But is llvm-gcc the right place to do that? The > changes that I discussed with Chris were in code gen. It seems like > the front-end is not the best place to do that kind of optimization > and that ideally the optimizer would be able to recognize that bitwise > vector operations do not depend on the element type."It depends" :) If the front-end is generating an intrinsic, it is useful for it to canonicalize the type. This constraints the intrinsic more. However, the code generator should accept and "do the right thing" with arbitrary shuffles. If the front-end is generating a shuffle instruction, the right place to handle this is in the code generator. Does that make sense? -Chris
On Aug 17, 2009, at 8:16 AM, Chris Lattner wrote:> On Aug 17, 2009, at 7:15 AM, Bob Wilson wrote: >> I committed a change to fix pr4731 yesterday but after thinking about >> it some more, I'd like to get other opinions about this. Chris and I >> talked last week about the need to canonicalize the types used for >> Neon vector shuffles so that they get CSEd. I guess this was an >> issue >> that came up for SSE. >> >> For pr4731, I changed llvm-gcc to canonicalize a bitwise vector >> operation to use i32 elements. For these operations, the type >> doesn't >> matter since the vector are treated as a bunch of bits. I was >> thinking that we should do the canonicalization for all the bitwise >> vector operations. But is llvm-gcc the right place to do that? The >> changes that I discussed with Chris were in code gen. It seems like >> the front-end is not the best place to do that kind of optimization >> and that ideally the optimizer would be able to recognize that >> bitwise >> vector operations do not depend on the element type. > > > "It depends" :) > > If the front-end is generating an intrinsic, it is useful for it to > canonicalize the type. This constraints the intrinsic more. > > However, the code generator should accept and "do the right thing" > with arbitrary shuffles. If the front-end is generating a shuffle > instruction, the right place to handle this is in the code generator. > > Does that make sense?Yes. It sounds like my intuition was right that the canonicalization should be handled in the code generator for this case where no intrinsics or shuffles are involved. I'll change it to use something like the patch that Sandeep included in the bug report. Thanks.