llvm dev - Jan 2009 - [LLVMdev] inline asm semantics: output constraint width smaller than input

On Jan 27, 2009, at 12:36 PM, Török Edwin wrote:
> On 2009-01-27 22:24, Duncan Sands wrote:
>> On Tuesday 27 January 2009 20:56:30 Mike Stump wrote:
>>
>>> On Jan 27, 2009, at 8:42 PM, Duncan Sands wrote:
>>>
>>>> one thing that seems to be clear to everyone except me is...
what
>>>> are the
>>>> semantics supposed to be?
>>>>
>>> I don't know of any other semantic other than, if they are  
>>> supposed to
>>> be in the same register, then they have to be in the same register.
>>>
>>
>> Sounds logical!  But what is the discussion about then?
>
> LLVM's Codegen is rejecting inline asm when input/output constraints
> have different bitwidths.
>
> For example in the Linux kernel calls to the various __put_user_
> functions take %al, %ax, %eax, %rax/ (%eax:%edx) as input parameter,
> and the output parameter is always an int (%eax). (hope I explained  
> this
> right)
Right, the interesting wrinkle is that I think llvm's codegen should  
only see matching constraints of the same type.  If the front-end sees  
an i8 tied to an i32, it should extend the i8 or do whatever else it  
needs to do.

-Chris

On 2009-01-27 23:00, Chris Lattner wrote:
> Right, the interesting wrinkle is that I think llvm's codegen should  
> only see matching constraints of the same type.  If the front-end sees  
> an i8 tied to an i32, it should extend the i8 or do whatever else it  
> needs to do.
>   
My only concern is whether codegen will be able to optimize away extra
extensions/truncations or not?
Consider  an i8 input, and i32 output. If the frontend extends the i8 so
that types match, the codegen should optimize away the extend eventually.
Otherwise we end up with useless extends in the generated assembly.

Best regards,
--Edwin

On Jan 27, 2009, at 1:17 PM, Török Edwin wrote:
> On 2009-01-27 23:00, Chris Lattner wrote:
>> Right, the interesting wrinkle is that I think llvm's codegen
should
>> only see matching constraints of the same type.  If the front-end  
>> sees
>> an i8 tied to an i32, it should extend the i8 or do whatever else it
>> needs to do.
>>
>
> My only concern is whether codegen will be able to optimize away extra
> extensions/truncations or not?
For truncates, yes, extensions no.
>
> Consider  an i8 input, and i32 output. If the frontend extends the  
> i8 so
> that types match, the codegen should optimize away the extend  
> eventually.
> Otherwise we end up with useless extends in the generated assembly.
The extend could be easily optimized away if llvm ir had a concept of  
"any extend" like codegen does.

-Chris

Hi Chris,
> > LLVM's Codegen is rejecting inline asm when input/output
constraints
> > have different bitwidths.
> >
> > For example in the Linux kernel calls to the various __put_user_
> > functions take %al, %ax, %eax, %rax/ (%eax:%edx) as input parameter,
> > and the output parameter is always an int (%eax). (hope I explained  
> > this
> > right)
> 
> Right, the interesting wrinkle is that I think llvm's codegen should  
> only see matching constraints of the same type.  If the front-end sees  
> an i8 tied to an i32, it should extend the i8 or do whatever else it  
> needs to do.
if I understand right the two cases are (for example):

(1): input (I) is i32, output (O) is i8.  In this case the asm output
type should be changed to i32 (O'), and O is obtained by truncating
O' to i8.

(2): input (I) is i8, output (O) is i32.  In this case the asm input
type should be changed to i32 (I'), and I' is obtained from I by
extending I to i32.

Is that it?

Thanks,

Duncan.

On Jan 27, 2009, at 11:41 PM, Duncan Sands wrote:
> Hi Chris,
>
>>> LLVM's Codegen is rejecting inline asm when input/output
constraints
>>> have different bitwidths.
>>>
>>> For example in the Linux kernel calls to the various __put_user_
>>> functions take %al, %ax, %eax, %rax/ (%eax:%edx) as input
parameter,
>>> and the output parameter is always an int (%eax). (hope I explained
>>> this
>>> right)
>>
>> Right, the interesting wrinkle is that I think llvm's codegen
should
>> only see matching constraints of the same type.  If the front-end  
>> sees
>> an i8 tied to an i32, it should extend the i8 or do whatever else it
>> needs to do.
>
> if I understand right the two cases are (for example):
>
> (1): input (I) is i32, output (O) is i8.  In this case the asm output
> type should be changed to i32 (O'), and O is obtained by truncating
> O' to i8.
>
> (2): input (I) is i8, output (O) is i32.  In this case the asm input
> type should be changed to i32 (I'), and I' is obtained from I by
> extending I to i32.
>
> Is that it?
Yes exactly.  On big endian targets a shift is also needed.

-Chris