"Rotem, Nadav" <nadav.rotem at intel.com> writes:> Can you describe which passes may benefit from this information ? My > intuition is that until there are a number of passes which require > this information, there are other ways to provide this > information. One way would be to use Metadata.We have Cray-specific passes that use this information. Some of the stuff Polly is doing almost certainly would benefit. Metadata seems a very clunky way to do this. It is so target-specific that it would render IR files completely target-dependent. These are rather complex structures we're talking about. Encoding it in metadata would be inconvenient.> Having said that, I do share the feeling that IR-level optimization > often need more target-specific information. For example, vectorizing > compilers need to know which instructions set the target has, etc.Yep, absolutely.> To this end, we have implemented a new 'instcombine-like' pass which > has optimizations which should have gone into 'instcombine' had we had > more information about the target.Right. Exposing some target attributes via generic queries (e.g. what's the max vector length for this scalar type?) has been on my wishlist for a while now. -Dave
On May 3, 2011, at 12:01 PM, David A. Greene wrote:> "Rotem, Nadav" <nadav.rotem at intel.com> writes: > >> Can you describe which passes may benefit from this information ? My >> intuition is that until there are a number of passes which require >> this information, there are other ways to provide this >> information. One way would be to use Metadata. > > We have Cray-specific passes that use this information. Some of the > stuff Polly is doing almost certainly would benefit.This sounds like an interesting addition, but we don't just speculatively add analysis passes to LLVM. Doing so leads to overdesign and lack of purpose. I'd suggest designing and implementing a specific loop optimization pass, hard coding it to a specific target, then generalize it by adding a way to get target parameters. This is how LSR was built, for example, which drove the address mode selection stuff.> Metadata seems a very clunky way to do this. It is so target-specific > that it would render IR files completely target-dependent. These are > rather complex structures we're talking about. Encoding it in metadata > would be inconvenient.I agree that metadata isn't the right way to go, but this argument doesn't fly at all with me. The whole point of these passes are to do target-specific optimizations. The right way to expose this sort of thing is with the new TargetRegistry interfaces. That said, speculatively adding target hooks isn't the right way to go, the client should come first. -Chris
Chris Lattner <clattner at apple.com> writes:> On May 3, 2011, at 12:01 PM, David A. Greene wrote: > >> "Rotem, Nadav" <nadav.rotem at intel.com> writes: >> >>> Can you describe which passes may benefit from this information ? My >>> intuition is that until there are a number of passes which require >>> this information, there are other ways to provide this >>> information. One way would be to use Metadata. >> >> We have Cray-specific passes that use this information. Some of the >> stuff Polly is doing almost certainly would benefit. >> This sounds like an interesting addition, but we don't just > speculatively add analysis passes to LLVM.Well, we do have such an analysis pass. I simply can't make it public. My plan was to provide the information we use today and leave enhancements to others as they are needed.> Doing so leads to overdesign and lack of purpose. I'd suggest > designing and implementing a specific loop optimization pass, hard > coding it to a specific target, then generalize it by adding a way to > get target parameters. This is how LSR was built, for example, which > drove the address mode selection stuff.Unfortunately, I don't have the bandwidth to design a whole new loop pass. If someone has the time and interest I would be very happy to work with those people.>> Metadata seems a very clunky way to do this. It is so target-specific >> that it would render IR files completely target-dependent. These are >> rather complex structures we're talking about. Encoding it in metadata >> would be inconvenient. >> I agree that metadata isn't the right way to go, but this argument > doesn't fly at all with me. The whole point of these passes are to do > target-specific optimizations.Yes, but one may want to take a single IR file and target multiple machines from it.> The right way to expose this sort of thing is with the new > TargetRegistry interfaces. That said, speculatively adding target > hooks isn't the right way to go, the client should come first.Ok, I will look at TargetRegistry. And again, it isn't speculative, it's just not public. -Dave