[llvm] r209007 - Fix most of PR10367.

John McCall rjmccall at apple.com
Sun May 18 19:20:20 PDT 2014

On May 18, 2014, at 4:53 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> This is all good, but none of them are the accepted process for proposing
>> a design change to IR, which is to send a detailed proposal to the
>> discussion list and wait a reasonable amount of time for consensus to
>> develop.
> The bug was open in 2011-07-15 by Chris. That seems to have achieved
> the objective of having a discussion about its tradeoffs. If you think
> that is bad practice to report bugs with design issues, please
> complain with the bug reporter.
> Please also take the time to review the other emails/bugs that were
> sent to avoid something like this happening again.

I don’t think it’s a bad practice to open bugs with design issues, I just think
that you should not treat that as a substitute for a detailed proposal sent
to llvm-dev.  Including a link to the PR saying “we’ve talked about it a lot
here” is fine.  Telling me that, in order to have an opinion on IR design,
I need to keep up with llvm-commits, the entire bug tracker, and your personal
discussions with Chris at the developers’ conference is not okay.

>> We have patches, that we aren’t yet certain are ready for trunk, that allow
>> GEPs in global aliases, which I think is a very clean way to expressed
>> offsetted aliases.
> And I, and everyone that had so far voiced an opinion about it
> disagree.

I have not seen any discussion about offsets.  Certainly the PR doesn’t
talk about that as a possibility; Chris’s comments even specifically call out
the fact that GEPs are allowed as a terrible thing (because they’re just
another redundant case to look through when all the feature’s allowed to
do is change the type).

To me, it seems pretty clear that the right design for a feature that’s only
ever a direct alias, but which can change the type, is probably not going to
be the right design for a feature that has accumulated even slightly more
expressive power than that.

>> Those patches are now basically impossible to apply
>> because you’ve deliberately neutered the representation of global aliases.
>> Now, obviously, you don’t have a responsibility to allow our out-of-tree
>> patches to apply cleanly, and I also know that you’re working on
>> adding offsets, which will address our immediate need.  Nonetheless, I’m
>> concerned that you’re taking global aliases in a needlessly restrictive
>> direction.
> Then follow the high standards you mentioned above. Once you have a
> use that actually requires something that is not a byte offset, start
> a discussion on the best way to represent it.

Here's an obvious one: a global alias to a ConstantInt (maybe inttoptr’ed)
is a really natural way to express an absolute symbol.


More information about the llvm-commits mailing list