[llvm-commits] [llvm] r40520 - in /llvm/trunk: include/llvm/CodeGen/ScheduleDAG.h lib/CodeGen/SelectionDAG/ScheduleDAG.cpp

Christopher Lamb christopher.lamb at gmail.com
Fri Jul 27 12:30:06 PDT 2007


On Jul 27, 2007, at 12:07 PM, Evan Cheng wrote:

>
> On Jul 26, 2007, at 11:52 PM, Christopher Lamb wrote:
>
>>
>> On Jul 26, 2007, at 10:28 PM, Evan Cheng wrote:
>>
>>> I don't think they are target opcodes.
>>
>> Is that a suggestion? In the implementation they are:
>>
>> --- llvm/trunk/include/llvm/Target/TargetInstrInfo.h (original)
>> +++ llvm/trunk/include/llvm/Target/TargetInstrInfo.h Thu Jul 26  
>> 02:48:21 2007
>> @@ -177,7 +177,9 @@
>>    enum {
>>      PHI = 0,
>>      INLINEASM = 1,
>> -    LABEL = 2
>> +    LABEL = 2,
>> +    EXTRACT_SUBREG = 3,
>> +    INSERT_SUBREG = 4
>>    };
>>
>
> Ah, I see. Although I don't think this is necessary especially  
> since they will be eliminated eventually. Can you treat them the  
> same way as CopyToReg and CopyFromReg?

Unfortunately not. CopyToReg and CopyFromReg are selected to native  
target instructions in SelectionDAG. The point of EXTRACT_SUBREG and  
INSERT_SUBREG is that they exist until (or even through) register  
allocation. These machine instructions carry information about which  
subregister and/or superregister is involved in the operation and  
cannot be eliminated until that information is no longer needed,  
either in coalescing or in the LowerSubregs pass.

> Just add the operands to isel queue and don't select to a new node.  
> If that works, we can remove TargetInstrInfo::EXTRACT_SUBREG, etc.

This is counter to the approach that we discussed at the meeting at  
Apple. The decision was to have insert/extract machine instructions  
to track the information through register allocation. Selecting the  
operands and not emitting a node would end up with wrong live ranges,  
as LV/LI have no clue that the vregs involved are aliasing. I've  
tried an approach that affects something similar to what you  
describe, it involves using the wrong class for instructions (see  
http://llvm.org/bugs/show_bug.cgi?id=1350 comment #9). This approach  
depended on the subreg index on all MachineInstrs which we decided to  
remove, and IIRC it was decided that this was generally "not the way".

--
Chris

>>> These are similar to phi, copyfromreg, etc.
>>
>> Not quite. The copyfrom/to reg and inlineasm nodes are ISD DAG  
>> nodes and are actually ISel'd in ScheduleDAG to the  
>> TargetInstrInfo types.
>>
>>> Target opcodes are those that are target specific, I.e. not  
>>> shared between targets.
>>
>> They're part of the low instruction numbers for all targets.
>> --
>> Chris
>>
>>> On Jul 26, 2007, at 8:36 PM, Christopher Lamb  
>>> <christopher.lamb at gmail.com> wrote:
>>>
>>>>
>>>> On Jul 26, 2007, at 6:27 PM, Evan Cheng wrote:
>>>>
>>>>>
>>>>> On Jul 26, 2007, at 1:12 AM, Christopher Lamb wrote:
>>>>>
>>>>>>  /// EmitNode - Generate machine code for an node and needed  
>>>>>> dependencies.
>>>>>>  ///
>>>>>>  void ScheduleDAG::EmitNode(SDNode *Node,
>>>>>> @@ -436,6 +578,14 @@
>>>>>>    // If machine instruction
>>>>>>    if (Node->isTargetOpcode()) {
>>>>>>      unsigned Opc = Node->getTargetOpcode();
>>>>>> +
>>>>>> +    // Handle subreg insert/extract specially
>>>>>> +    if (Opc == TargetInstrInfo::EXTRACT_SUBREG ||
>>>>>> +        Opc == TargetInstrInfo::INSERT_SUBREG) {
>>>>>> +      EmitSubregNode(Node, VRBaseMap);
>>>>>> +      return;
>>>>>> +    }
>>>>>> +
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> Is this right? EXTRACT_SUBREG and INSERT_SUBREG are not target  
>>>>> opcodes.
>>>>
>>>> Actually, they are both DAG nodes and target opcodes. ISel  
>>>> lowers the DAG nodes to target opcodes before schedule DAG sees  
>>>> them.
>>>> --
>>>> Christopher Lamb
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>> --
>> Christopher Lamb
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

--
Christopher Lamb



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20070727/7708b1d8/attachment.html>


More information about the llvm-commits mailing list