<div dir="ltr">Relaxation causes instructions to get larger. We optimistically assume that we can encode a relative jump using a 1 byte immediate until we prove that we can't. We will then switch to a 4 byte immediate.<div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 10, 2018 at 2:06 PM John Criswell via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 7/10/18 1:48 PM, Cranmer, Joshua via llvm-dev wrote:<br>
> The actual size of even a MC instruction will change during relaxation--we don't choose between 8-bit jumps and wider jumps until relaxation. You can get the actual encoding of an MCInst via MCCodeEmitter, but if you expect relaxation to occur, or particularly if you're testing before register allocation, the size could only be an estimate and shouldn't be trusted for exact size.<br>
<br>
Thanks.  I should be doing this as the last pass before emission to the <br>
object file, so it is post register allocation.<br>
<br>
Will relaxation cause an instruction to become larger or only smaller?  <br>
If the instruction ends up being smaller, that is fine. If it can get <br>
larger, that could be a problem.<br>
<br>
I'll take a look at MCCodeEmitter.<br>
<br>
Thanks,<br>
<br>
John Criswell<br>
<br>
><br>
> -----Original Message-----<br>
> From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>] On Behalf Of Matthias Braun via llvm-dev<br>
> Sent: Tuesday, July 10, 2018 13:21<br>
> To: John Criswell <<a href="mailto:jtcriswel@gmail.com" target="_blank">jtcriswel@gmail.com</a>><br>
> Cc: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> Subject: Re: [llvm-dev] Finding Size of X86 instruction in MachineFunctionPass<br>
><br>
> I don't think this API exists for machine function passes. It also wouldn't be too useful because the size of the instruction depends on details like which register is assigned  which could be changed by later machine passes. Of course during emission the MC layer should have an idea of how big instructions become, so your best bet is probably to modify the compiler at this point (I cannot give tips to that though as I'm not that familiar with these parts).<br>
><br>
> - Matthias<br>
><br>
>> On Jul 10, 2018, at 7:29 AM, John Criswell via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Dear All,<br>
>><br>
>> Is there a way in newer versions of LLVM (4.0 and higher) to find the size of an x86 instruction within a MachineFunctionPass?  If not, is there something I can do in the MC layer to do this?<br>
>><br>
>> I'm trying to modify LLVM to implement something like Native Client in which groups of instructions are aligned at a specific alignment and have the same length.  My current approach is to split each MachineBasicBlock so that it is less than or equal to the desired size and then align each MachineBasicBlock at the proper alignment.  However, I've been poking around doxygen and can't find anything that will give me the size of an x86 instruction.<br>
>><br>
>> Thanks in advance,<br>
>><br>
>> John Criswell<br>
>><br>
>> --<br>
>> John Criswell<br>
>> Assistant Professor<br>
>> Department of Computer Science, University of Rochester<br>
>> <a href="http://www.cs.rochester.edu/u/criswell" rel="noreferrer" target="_blank">http://www.cs.rochester.edu/u/criswell</a><br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
<br>
-- <br>
John Criswell<br>
Assistant Professor<br>
Department of Computer Science, University of Rochester<br>
<a href="http://www.cs.rochester.edu/u/criswell" rel="noreferrer" target="_blank">http://www.cs.rochester.edu/u/criswell</a><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>