<div dir="ltr"><div>+// FIXME: Delete this in LLVM 4.0 and just assert that the aliasse is a</div><div><br></div><div>"aliasee"  Chrome doesn't think it's a word, but our API has getAliasee, so let's go with it.</div>

<div><br></div><div>+// GlobalObject.</div><div><div>+static GlobalObject &</div><div>+getGlobalObjectInExpr(const DenseMap<GlobalAlias *, Constant *> &Map,</div><div>+                      Constant &C) {</div>

<div>+  auto *GO = dyn_cast<GlobalObject>(&C);</div><div>+  if (GO)</div><div>+    return *GO;</div><div>+  auto *GA = dyn_cast<GlobalAlias>(&C);</div><div>+  if (GA)</div><div>+    return getGlobalObjectInExpr(Map, *Map.find(GA)->second);</div>

<div>+  auto &CE = cast<ConstantExpr>(C);</div><div>+  assert(CE.getOpcode() == Instruction::BitCast ||</div><div>+         CE.getOpcode() == Instruction::GetElementPtr ||</div><div><br></div><div><div>We never supported GEPs to non-zero offsets, right?  Should we assert that or check that here?</div>

</div><div><br></div><div>+         CE.getOpcode() == Instruction::AddrSpaceCast);</div><div>+  return getGlobalObjectInExpr(Map, *CE.getOperand(0));</div><div>+}</div></div><div><br></div><div><br></div><div><div>+  // FIXME: Delete this in LLVM 4.0</div>

<div>+  // Older versions of llvm could write an alias pointing to another. We cannot</div><div>+  // construct those aliases, so we first collect an alias to aliasee expression</div><div>+  // and then compute the actual aliassee.</div>

<div><br></div><div>"aliasee"</div><div><br></div><div>+  DenseMap<GlobalAlias*, Constant *> AliasInit;</div></div><div><br></div><div><div>+  for (auto &Pair : AliasInit) {</div><div>+    setAliasProperties(AliasInit, *Pair.first, *Pair.second);</div>

<div><br></div><div>This function is called once, I'd just inline it.</div><div><br></div><div>+  }</div></div><div><br></div><div><br></div><div><div>-      GVar = dyn_cast_or_null<GlobalVariable>(GA->getAliasedGlobal());</div>
<div>+      GVar = dyn_cast_or_null<GlobalVariable>(GA->getAliasee());</div></div><div><br></div><div>This rename accounts for a large portion of the diff.  Is it worth committing separately?</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, May 12, 2014 at 9:52 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">
These patches change the design of GlobalAlias so that it doesn't take<br>
a ConstantExpr anymore.<br>
<br>
First, sorry for such large patches, but I am out of ideas on how to<br>
split them further. The patches are:<br>
<br>
* llvm-1.patch: Split GlobalValue into GlobalValue and GlobalObject.<br>
That allows us statically accept a Function or a GlobalVariable, but<br>
not an alias. This is already a cleanup by itself IMHO, but the main<br>
reason is that it gives a lot more confidence that the next patch is<br>
doing the right thing.<br>
<br>
* clang-1.patch is just an update for the api change.<br>
<br>
These two patches are already fairly mature. The next two still need<br>
polishing and some bug fixes, but it should already be possible to<br>
provide feedback on some high level issues. In particular:<br>
<br>
To avoid changing all alias related tests in these patches, I kept the<br>
common syntax<br>
<br>
@foo = alias i32* @bar<br>
<br>
to mean the same as now. The more general case when the types don't<br>
match is written<br>
<br>
@foo = alias i16, i32* @bar.<br>
<br>
Note that GlobalAlias now behaves a bit more like GlobalVariable. We<br>
know that its type is always a pointer, so we omit the '*'.<br>
<br>
For the bitcode, a nice surprise is that we were writing both<br>
identical types already, so the format change is minimal. Auto upgrade<br>
is handled by looking through the casts and no new fields are needed<br>
for now. New bitcode will simply have different types for Alias and<br>
Aliassee.<br>
<br>
One last interesting point in the patch is that replaceAllUsesWith<br>
becomes smart enough to avoid putting a ConstantExpr in the aliassee.<br>
This seems better than checking and updating every caller.<br>
<br>
What is still not implemented (and will be done in a followup patch)<br>
is to add an offset field, so that we can represent an alias that is<br>
inside another symbol.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>