[llvm] r209007 - Fix most of PR10367.
rafael.espindola at gmail.com
Sun May 18 16:53:53 PDT 2014
> 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
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.
> 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. If you were to use a feature that is not used by anything
else and currently completely broken, it was up to you to send a
message about it.
I will have a patch for review for adding offsets for aliases today,
so it looks like the total delay you will get is less than a week.
> 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
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.
More information about the llvm-commits