<div dir="ltr">Hi Rafael,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">But it does so in the wrong place. It doesn't handle things like A +<br>expr_that_evaluates_to_zero.<br></blockquote><div><br></div><div>Where would we handle that under your proposal? As far as I know MC doesn't have a robust symbolic arithmetic expression evaluator. What happens if the user types</div><div><br></div><div>foo:</div><div>        nop</div><div>bar = . + expr_that_evals_to_foo_minus_bar.</div><div><br></div><div>?</div><div><br></div><div>This is no worse than the bug you pointed out, but no better either. The real fix for this is to teach ld64 to allow the alt_entry bit on direct aliases, then just set it for all alias expressions. I have an internal bug filed for that.</div><div><br></div><div>In the mean time, using .alt_entry at least guarantees that the resulting expression is of the form 'Label + C' which can be easily recognized.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">ideally you </span><span style="font-size:13px">would avoid MC even creating new fragments. To do that, what is needed<br></span><span style="font-size:13px">is to add the restriction that ".alt_entry foo" comes  before "foo:".</span></blockquote><div><br></div><div>Agreed. I'll figure out how to add that.</div><div><br></div><div><div class="gmail_extra">- Lang.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 22, 2016 at 8:25 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 22 March 2016 at 11:20, Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br>
> Hi Rafael,<br>
><br>
</span><span class="">> Apologies - mis-hit the send button. Continuing on...<br>
><br>
> My patch special-cased 'foo + 0' to behave the same as 'foo' - ld64<br>
> recognizes aliases for the same location and treats them as one atom. We<br>
> only need to set the alt_entry bit on 'foo + C', where C is non-zero.<br>
<br>
</span>But it does so in the wrong place. It doesn't handle things like A +<br>
expr_that_evaluates_to_zero.<br>
<br>
Codegen can just print<br>
<br>
sym = expr<br>
<br>
and let MC do the work. If expr is zero, no need to output the flag.<br>
If non-zero, emit the flag.<br>
<span class=""><br>
>> As noted in the review this introduces a different bug with regards to<br>
>> ld and llvm-mc not agreeing about which symbols are atoms.<br>
><br>
><br>
> This is unfortunate, but the new bug is benign: at worst you get redundant<br>
> relocations. With a bit of work in MC I can probably get rid of these too.<br>
> The old bug was much more dangerous - you could end up with code that needed<br>
> relocations and didn't have any.<br>
<br>
</span>It is still somewhat dangerous bug as people can become dependent on<br>
it. Avoiding the relocation shouldn't be too hard, but ideally you<br>
would avoid MC even creating new fragments. To do that, what is needed<br>
is to add the restriction that ".alt_entry foo" comes  before "foo:".<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div></div>