llvm dev - Oct 2014 - [LLVMdev] Stange behavior in fp arithmetics on x86 (bug possibly)

On Oct 7, 2014, at 2:26 PM, Tim Northover <t.p.northover at gmail.com>
wrote:
> Hi Dmitry,
> 
> On 7 October 2014 10:50, Dmitry Borisenkov <d.borisenkov at
samsung.com> wrote:
>> fpfail.s:26: Error: invalid instruction suffix for `ret'
>> 
>> I downloaded Intel manual and haven’t found any mention of retl
instruction,
> 
> "retl" is the AT&T syntax for the normal "ret"
instruction in the
> Intel manual, which makes it mostly undocumented.
Are you sure about that? I don't recall ever seeing retl before. A while
back a reference for AT&T was mentioned and, as I recall, this was the best
anyone had <http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf>. It
contains no mention of retl.

This seems to be the commit that added support for it
<http://lists.cs.uiuc.edu/pipermail/llvm-branch-commits/2010-May/003229.html>.

I'm not sure I understand the distinction between retl/retq. x86 has 4
return instruction (cribbing from the Intel manual):

C3	RET		Near return
CB	RET		Far return
C2 iw	RET imm16	Near return + pop imm16 bytes
CA iw	RET imm16	Far return + pop imm16 bytes

(And I think that's been true since the 8086.)

Distinguishing between near and far (e.g., ret vs. lret in AT&T or retn vs.
retf with some other assemblers) makes sense, but what would a l or q suffix
denote?

But more to the point, even if there's a good reason to accept retl/retq as
input, is there any reason to emit it ever?

-- 
Stephen Checkoway

r198756 seems to be related too. That would explain why the difference
appears in 3.5 relative to 3.4.

On Thu, Oct 9, 2014 at 11:48 PM, Stephen Checkoway <s at pahtak.org>
wrote:
>
> On Oct 7, 2014, at 2:26 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
>
> > Hi Dmitry,
> >
> > On 7 October 2014 10:50, Dmitry Borisenkov <d.borisenkov at
samsung.com>
> wrote:
> >> fpfail.s:26: Error: invalid instruction suffix for `ret'
> >>
> >> I downloaded Intel manual and haven’t found any mention of retl
> instruction,
> >
> > "retl" is the AT&T syntax for the normal "ret"
instruction in the
> > Intel manual, which makes it mostly undocumented.
>
> Are you sure about that? I don't recall ever seeing retl before. A
while
> back a reference for AT&T was mentioned and, as I recall, this was the
best
> anyone had
<http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf>.
> It contains no mention of retl.
>
> This seems to be the commit that added support for it <
> http://lists.cs.uiuc.edu/pipermail/llvm-branch-commits/2010-May/003229.html
> >.
>
> I'm not sure I understand the distinction between retl/retq. x86 has 4
> return instruction (cribbing from the Intel manual):
>
> C3      RET             Near return
> CB      RET             Far return
> C2 iw   RET imm16       Near return + pop imm16 bytes
> CA iw   RET imm16       Far return + pop imm16 bytes
>
> (And I think that's been true since the 8086.)
>
> Distinguishing between near and far (e.g., ret vs. lret in AT&T or retn
> vs. retf with some other assemblers) makes sense, but what would a l or q
> suffix denote?
>
> But more to the point, even if there's a good reason to accept
retl/retq
> as input, is there any reason to emit it ever?
>
> --
> Stephen Checkoway
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141010/a7ee3fe0/attachment.html>

On 10.10.2014 9:48, Stephen Checkoway wrote:
>
> On Oct 7, 2014, at 2:26 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
>
>> Hi Dmitry,
>>
>> On 7 October 2014 10:50, Dmitry Borisenkov <d.borisenkov at
samsung.com> wrote:
>>> fpfail.s:26: Error: invalid instruction suffix for `ret'
>>>
>>> I downloaded Intel manual and haven’t found any mention of retl
instruction,
>>
>> "retl" is the AT&T syntax for the normal "ret"
instruction in the
>> Intel manual, which makes it mostly undocumented.
>
> Are you sure about that? I don't recall ever seeing retl before. A
while back a reference for AT&T was mentioned and, as I recall, this was the
best anyone had
<http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf>. It contains
no mention of retl.
>
> This seems to be the commit that added support for it
<http://lists.cs.uiuc.edu/pipermail/llvm-branch-commits/2010-May/003229.html>.
>
> I'm not sure I understand the distinction between retl/retq. x86 has 4
return instruction (cribbing from the Intel manual):
>
> C3	RET		Near return
> CB	RET		Far return
> C2 iw	RET imm16	Near return + pop imm16 bytes
> CA iw	RET imm16	Far return + pop imm16 bytes
>
> (And I think that's been true since the 8086.)
>
> Distinguishing between near and far (e.g., ret vs. lret in AT&T or retn
vs. retf with some other assemblers) makes sense, but what would a l or q suffix
denote?
>
> But more to the point, even if there's a good reason to accept
retl/retq as input, is there any reason to emit it ever?
>
Since in x86 you can mix 16-bit and 32-bit code, therefore you must be 
able to distinguish between 16-bit and 32-bit return. And from there 
comes the w and l suffix for the return instruction.

code16:
ret = retw => C3
retl => 66 C3

code32:
ret = retl => C3
retw => 66 C3

And what comes to q suffix, it is either to be consistent or it just got 
cargo-culted.

Pasi

On Oct 10, 2014, at 7:23 AM, Pasi Parviainen <pasi.parviainen at iki.fi>
wrote:
> On 10.10.2014 9:48, Stephen Checkoway wrote:
>> 
>> But more to the point, even if there's a good reason to accept
retl/retq as input, is there any reason to emit it ever?
>> 
> 
> Since in x86 you can mix 16-bit and 32-bit code, therefore you must be able
to distinguish between 16-bit and 32-bit return. And from there comes the w and
l suffix for the return instruction.
Makes total sense. I didn't think about using the operand size override. (I
didn't even realize that was legal for ret.)

Thanks,

-- 
Stephen Checkoway