SUBREG instructions and mayLoad/mayStore/etc.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

SUBREG instructions and mayLoad/mayStore/etc.

Dan Gohman-2
The new SUBREG target-independent instructions aren't getting
mayLoad/mayStore flags set correctly.

For example, in the generated X86GenInstrInfo.inc file,
there is only one entry for INSERT_SUBREG:

   { 5,  4,      1,      0,      "INSERT_SUBREG", 0, 0, NULL, NULL,  
OperandInfo107 },  // Inst #5 = INSERT_SUBREG

THe sixth field is zero, which means it doesn't have the the
MayLoad flag set.

x86-64 does have a few variants of INSERT_SUBREG, and one of
them does have a load:

def : Pat<(i64 (anyext (loadi32 addr:$src))),
           (INSERT_SUBREG (i64 (IMPLICIT_DEF)), (MOV32rm addr:$src),
                                                     x86_subreg_32bit)>;

This isn't currently being reflected in the InstrInfo tables.
Naively, it seems like we should add a separate INSERT_SUBREGrm
instruction, and so on, or something like that, in order to be able
to have accurate InstrInfo tables. Does anyone familiar with the
new subregs infastructure have an opinion on this?

Dan

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: SUBREG instructions and mayLoad/mayStore/etc.

Evan Cheng-2

On Mar 18, 2008, at 6:12 PM, Dan Gohman wrote:

> The new SUBREG target-independent instructions aren't getting
> mayLoad/mayStore flags set correctly.
>
> For example, in the generated X86GenInstrInfo.inc file,
> there is only one entry for INSERT_SUBREG:
>
>   { 5,  4,      1,      0,      "INSERT_SUBREG", 0, 0, NULL, NULL,
> OperandInfo107 },  // Inst #5 = INSERT_SUBREG
>
> THe sixth field is zero, which means it doesn't have the the
> MayLoad flag set.

I am not sure I understand. INSERT_SUBREG shouldn't have mayLoad /  
mayStore flags set. If it's not coalesced away, it's eventually  
lowered into a move.

>
>
> x86-64 does have a few variants of INSERT_SUBREG, and one of
> them does have a load:
>
> def : Pat<(i64 (anyext (loadi32 addr:$src))),
>           (INSERT_SUBREG (i64 (IMPLICIT_DEF)), (MOV32rm addr:$src),
>                                                      
> x86_subreg_32bit)>;
>
>
> This isn't currently being reflected in the InstrInfo tables.
> Naively, it seems like we should add a separate INSERT_SUBREGrm
> instruction, and so on, or something like that, in order to be able
> to have accurate InstrInfo tables. Does anyone familiar with the
> new subregs infastructure have an opinion on this?

This is saying the pattern should be isel into two instructions.  
MOV32rm is obviously a load, but INSERT_SUBREG doesn't load or store.

Evan

>
>
> Dan
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: SUBREG instructions and mayLoad/mayStore/etc.

Dan Gohman-2

On Mar 18, 2008, at 6:23 PM, Evan Cheng wrote:
>>
>> This isn't currently being reflected in the InstrInfo tables.
>> Naively, it seems like we should add a separate INSERT_SUBREGrm
>> instruction, and so on, or something like that, in order to be able
>> to have accurate InstrInfo tables. Does anyone familiar with the
>> new subregs infastructure have an opinion on this?
>
> This is saying the pattern should be isel into two instructions.
> MOV32rm is obviously a load, but INSERT_SUBREG doesn't load or store.

Thanks, this is where I was confused.

Dan

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev