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

[Evan Cheng]

On Jul 27, 2007, at 12:30 PM, Christopher Lamb wrote:

>
> 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".

Ok, I'd forgotten each MI does need a TargetInstrDescriptor so it  
cannot reuse ISD::EXTRACT_SUBREG. Never mind. Sorry about the  
confusion. :-)

Evan

>
> --
> 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
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

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