<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 30, 2018 at 6:51 PM, Rafael Avila de Espindola <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">Ryan Prichard via Phabricator via llvm-commits<br>
<<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> writes:<br>
<br>
> +// ELF:   Name: .data<br>
> +// MACHO: Name: __data<br>
> +// CHECK: SectionData (<br>
> +// CHECK:   0000: 112233FF 7FCDCDCD CDCDCDCD CDCDCDCD<br>
> +// CHECK:   4000: CDCD0000 01020304<br>
> +// CHECK: )<br>
<br>
CHECK-NEXT maybe?<br>
<br>
> +// ELF:   Name: .data<br>
> +// MACHO: Name: __data<br>
> +// CHECK: SectionData (<br>
> +// CHECK:   0000: FF01FFFF 00CDCDCD CDCDCDCD CDCDCDCD<br>
> +// CHECK:   4000: CDCDCDCD 01020304<br>
> +// CHECK: )<br>
<br>
CHECK-NEXT maybe? <br></blockquote><div><br></div><div>I think both the "0000:" and the ")" lines can be changed to CHECK-NEXT. I can make those changes.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> +  // Sometimes the compiler generates EH table assembly that is impossible to<br>
> +  // assemble without either adding padding to an LEB fragment or adding extra<br>
> +  // padding to a later alignment fragment. Allow an LEB fragment's size to<br>
> +  // shrink a few times, then prevent it from further shrinking. See PR35809.<br>
<br>
This is not LEB specific. A branch getting bigger can put another branch<br>
in range for a smaller encoding. If we are to support this it should be<br>
a general property of the relaxation loop.<br>
<br>
I would suggest leaving this out of the initial fix.<br></blockquote><div><br></div><div>That makes sense. I'll take out the LEB "relax allowances" behavior.</div><div><br></div><div>I'm not sure whether to update uleb-optimal.s with a padded LEB or remove it. I think I'm inclined to remove it. It doesn't test anything that uleb-ehtable.s doesn't test, and it would fail on previous LLVM assemblers without indicating a bug in them.</div><div><br></div><div>Thanks,</div><div>-Ryan</div><div><br></div></div></div></div>