<div dir="ltr">I feel like this entire discussion is somewhat pointless in its current form.<div><br></div><div>I actually very much share John's concern about what the right general approach here is for LLVM's IR and it isn't 100% clear that what we have right now *is* the right solution. I'm actually quite dubious.</div>
<div><br></div><div>The fact of the matter is that we haven't had any proper design discussion other than an old PR with limited audience attached. =/ That means the right set of eyes weren't on this issue for better or worse. What we have right now, AFAICT, *is* consistent with the express intent of the bug and the express tested usages of the feature in LLVM. I don't think we can do a good job of designing the right end-state abstraction without, well, a design. Including motivating use cases, examples, and test cases. Currently we don't have any of that.</div>
<div><br></div><div>So, John, can you please propose how you thing aliases *should* work to llvmdev, with test cases and examples to motivate this? I like the design you seem to be aiming at, but frankly, I don't have nearly as good of design examples or test cases. You'll be able to make a better and more concrete proposal for how this *should* work.</div>
<div><br></div><div>And then Rafael and you can argue about how to support specific operations (like RAUW) and figure out how best to support those.</div><div><br></div><div>I'm moderately confident that we can easily auto-upgrade bitcode to and from all of these variants without trouble, so I don't see what's wrong leaving the current (very minimal and perhaps annoyingly un-featureful) design in tree until we have a reasonably agreed-upon design for something more complex?</div>
<div><br></div><div>-Chandler</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 19, 2014 at 11:42 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> I don’t think it’s a bad practice to open bugs with design issues, I just think<br>
> that you should not treat that as a substitute for a detailed proposal sent<br>
> to llvm-dev.  Including a link to the PR saying “we’ve talked about it a lot<br>
> here” is fine.  Telling me that, in order to have an opinion on IR design,<br>
> I need to keep up with llvm-commits, the entire bug tracker, and your personal<br>
> discussions with Chris at the developers’ conference is not okay.<br>
<br>
</div>I keep to saying that in the years this has been up you should have<br>
been able to noticed it and that is a reasonable expectation.<br>
<br>
It also seems you are holding me to a higher standard than yourself.<br>
If you started to use a feature that we could not ever stream<br>
correctly via bitcode and we have a bug about dropping. It seems you<br>
are the one that would have the much higher burden of proposing a<br>
change: geps with non zero offsets.<br>
<div class=""><br>
> Here's an obvious one: a global alias to a ConstantInt (maybe inttoptr’ed)<br>
> is a really natural way to express an absolute symbol.<br>
<br>
</div>Or an offset from null. I quiet like the feature. I will try to come<br>
up with a patch for it once the current one is done.<br>
<br>
Cheers,<br>
Rafael<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>