[llvm-commits] [llvm] r48130 - in /llvm/trunk: include/llvm/CodeGen/SelectionDAGNodes.h lib/CodeGen/LowerSubregs.cpp lib/CodeGen/SelectionDAG/ScheduleDAG.cpp lib/Target/Target.td lib/Target/X86/X86ISelDAGToDAG.cpp lib/Target/X86/X86Instr64bit.td lib/Target/X86/X86InstrInfo.cpp lib/Target/X86/X86InstrInfo.h lib/Target/X86/X86InstrInfo.td lib/Target/X86/X86RegisterInfo.h lib/Target/X86/X86RegisterInfo.td
Christopher Lamb
christopher.lamb at gmail.com
Tue Mar 11 23:39:28 PDT 2008
On Mar 11, 2008, at 1:01 PM, Evan Cheng wrote:
>
> On Mar 11, 2008, at 12:19 AM, Christopher Lamb wrote:
>
>>
>> On Mar 11, 2008, at 12:01 AM, Evan Cheng wrote:
>>
>>> Dan works at Apple now. :-)
>>
>> Just noticed.
>>
>>> I'm not sure I completely understand this. Are you saying
>>> insert_subreg, extract_subreg isel patterns checks for
>>> memoperands? Why would there be any?
>>
>> The reason that there would be any memoperands is that the
>> DAGIselEmiter generates isel code which always attaches
>> memoperands for a pattern containing loads and stores to the root
>> node of the generated instruction pattern.
>
> So this is the issue that impact patterns which fold insert_subreg
> as zextload for x86-64? Are these the parts that you left out of
> the re-commit?
This was one part of it. Another problem is that it isn't safe to
eliminate the subreg copy for insert_subreg with target semantics,
unless the rest of the register can be undef. I've made modifications
that make this explicit in LowerSubregs, and also makes undef, and
zero implict inserts target independent (though not necessarily
supported, that's up to a back end to use it or not). This solved the
problem in the tests that were failing.
--
Chris
>
>>
>> So a theoretical pattern:
>>
>> Pat<(zextloadi8 B), (SHR (SHL (LOAD B), 24), 24)>;
>>
>> will have the memoperands attached to the generated SHR node. In
>> addition it appears that a chain operand may be added to the SHR,
>> and SHL nodes as well.
>> --
>> Chris
>>
>>>
>>> Evan
>>>
>>> On Mar 10, 2008, at 10:03 PM, Christopher Lamb wrote:
>>>
>>>> One problem appears to be that the TableGen DAGIsel emitter
>>>> places the MemOperand used for tracking memory accesses always,
>>>> and only, on the root node of the pattern, regardless of whether
>>>> or not that instruction actually accesses memory. For insert/
>>>> extract subreg the number of operands is checked explicitly, and
>>>> MemOperands are not ignored, causing asserts in the back end.
>>>>
>>>> Dan, is there a reason that these are always affixed to the root
>>>> node of the pattern? Is it a bug to do so?
>>>> --
>>>> Chris
>>>>
>>>> On Mar 10, 2008, at 11:19 AM, Evan Cheng wrote:
>>>>
>>>>> BTW, your patches have broken a number of x86-64 tests on Mac
>>>>> OS X:
>>>>>
>>>>> Applications/oggenc/oggenc [LLC compile, LLC-BETA compile, JIT
>>>>> codegen, LLC, LLC-BETA, JIT]
>>>>> Benchmarks/Trimaran/enc-3des/enc-3des [LLC compile, LLC-BETA
>>>>> compile,
>>>>> JIT codegen, LLC, LLC-BETA, JIT]
>>>>> Benchmarks/VersaBench/ecbdes/ecbdes [LLC compile, LLC-BETA
>>>>> compile,
>>>>> JIT codegen, LLC, LLC-BETA, JIT]
>>>>> SPEC/CINT2000/254.gap/254.gap [LLC compile, LLC-BETA compile, JIT
>>>>> codegen, LLC, LLC-BETA, JIT]
>>>>>
>>>>> Please fix. Thanks,
>>>>>
>>>>> Evan
>>>>>
>>>>> On Mar 10, 2008, at 10:51 AM, Evan Cheng wrote:
>>>>>
>>>>>> This is to implement x86-64 implicit zero extension? Very
>>>>>> nice. Some
>>>>>> comments below:
>>>>>>
>>>>>> Evan
>>>>>>
>>>>>> On Mar 9, 2008, at 11:12 PM, Christopher Lamb wrote:
>>>>>>
>>>>>>> Author: clamb
>>>>>>> Date: Mon Mar 10 01:12:08 2008
>>>>>>> New Revision: 48130
>>>>>>>
>>>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=48130&view=rev
>>>>>>> Log:
>>>>>>> Allow insert_subreg into implicit, target-specific values.
>>>>>>> Change insert/extract subreg instructions to be able to be
>>>>>>> used in
>>>>>>> TableGen patterns.
>>>>>>> Use the above features to reimplement an x86-64 pseudo
>>>>>>> instruction
>>>>>>> as a pattern.
>>>>>>>
>>>>>>> Modified:
>>>>>>> llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h
>>>>>>> llvm/trunk/lib/CodeGen/LowerSubregs.cpp
>>>>>>> llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp
>>>>>>> llvm/trunk/lib/Target/Target.td
>>>>>>> llvm/trunk/lib/Target/X86/X86ISelDAGToDAG.cpp
>>>>>>> llvm/trunk/lib/Target/X86/X86Instr64bit.td
>>>>>>> llvm/trunk/lib/Target/X86/X86InstrInfo.cpp
>>>>>>> llvm/trunk/lib/Target/X86/X86InstrInfo.h
>>>>>>> llvm/trunk/lib/Target/X86/X86InstrInfo.td
>>>>>>> llvm/trunk/lib/Target/X86/X86RegisterInfo.h
>>>>>>> llvm/trunk/lib/Target/X86/X86RegisterInfo.td
>>>>>>>
>>>>>>> Modified: llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h
>>>>>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/
>>>>>>> llvm/CodeGen/SelectionDAGNodes.h?
>>>>>>> rev=48130&r1=48129&r2=48130&view=diff
>>>>>>>
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> ================================================================
>>>>>>> =====
>>>>>>> --- llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h
>>>>>>> (original)
>>>>>>> +++ llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h Mon
>>>>>>> Mar 10
>>>>>>> 01:12:08 2008
>>>>>>> @@ -322,9 +322,12 @@
>>>>>>> // This node takes a superreg and a constant sub-register
>>>>>>> index
>>>>>>> as operands.
>>>>>>> EXTRACT_SUBREG,
>>>>>>>
>>>>>>> - // INSERT_SUBREG - This node is used to insert a sub-
>>>>>>> register
>>>>>>> value.
>>>>>>> + // INSERT_SUBREG - This node is used to insert a sub-
>>>>>>> register
>>>>>>> value into
>>>>>>> + // either explicitly into a superreg, or implicitly into a
>>>>>>> superreg value.
>>>>>>> // This node takes a superreg, a subreg value, and a constant
>>>>>>> sub-register
>>>>>>> - // index as operands.
>>>>>>> + // index as operands. The superreg may be either a
>>>>>>> superregister operand or a
>>>>>>> + // target constant indicating that the insert is being done
>>>>>>> into a target
>>>>>>> + // specific implicit value.
>>>>>>
>>>>>> Rather than some magic target specific implicit value. Why not
>>>>>> just
>>>>>> allow ISD::UNDEF or any immediate value?
>>>>>>
>>>>>>>
>>>>>>> INSERT_SUBREG,
>>>>>>>
>>>>>>> // MULHU/MULHS - Multiply high - Multiply two integers of
>>>>>>> type
>>>>>>> iN, producing
>>>>>>>
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> ================================================================
>>>>>>> =====
>>>>>>> --- llvm/trunk/lib/Target/X86/X86RegisterInfo.h (original)
>>>>>>> +++ llvm/trunk/lib/Target/X86/X86RegisterInfo.h Mon Mar 10
>>>>>>> 01:12:08
>>>>>>> 2008
>>>>>>> @@ -32,6 +32,15 @@
>>>>>>> };
>>>>>>> }
>>>>>>>
>>>>>>> +namespace X86 {
>>>>>>> + /// SubregIndex - The index of various sized subregister
>>>>>>> classes.
>>>>>>> Note that
>>>>>>> + /// these indices must be kept in sync with the class
>>>>>>> indices in
>>>>>>> the
>>>>>>> + /// X86RegisterInfo.td file.
>>>>>>> + enum SubregIndex {
>>>>>>> + SUBREG_8BIT = 1, SUBREG_16BIT = 2, SUBREG_32BIT = 3
>>>>>>> + };
>>>>>>> +}
>>>>>>> +
>>>>>>
>>>>>> Nice. Using enum is an improvement to magic constants. But how
>>>>>> about
>>>>>> making these target independent? However, that means adding a
>>>>>> bunch of
>>>>>> them which are not currently used: SUBREG_SECOND_8BIT, etc.
>>>>>> Instead,
>>>>>> perhaps you can add a helper function to map to the magic
>>>>>> indicies,
>>>>>> e.g. SubRegIndex(MVT::ValueType SuperRegVT, MVT::ValueType
>>>>>> SubRegVt,
>>>>>> unsigned WhichChunk)? What do you think?
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> /// DWARFFlavour - Flavour of dwarf regnumbers
>>>>>>> ///
>>>>>>> namespace DWARFFlavour {
>>>>>>>
>>>>>>> Modified: llvm/trunk/lib/Target/X86/X86RegisterInfo.td
>>>>>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/
>>>>>>> Target/X86/X86RegisterInfo.td?
>>>>>>> rev=48130&r1=48129&r2=48130&view=diff
>>>>>>>
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> ================================================================
>>>>>>> =====
>>>>>>> --- llvm/trunk/lib/Target/X86/X86RegisterInfo.td (original)
>>>>>>> +++ llvm/trunk/lib/Target/X86/X86RegisterInfo.td Mon Mar 10
>>>>>>> 01:12:08
>>>>>>> 2008
>>>>>>> @@ -176,6 +176,10 @@
>>>>>>> // sub registers for each register.
>>>>>>> //
>>>>>>>
>>>>>>> +def x86_subreg_8bit : PatLeaf<(i32 1)>;
>>>>>>> +def x86_subreg_16bit : PatLeaf<(i32 2)>;
>>>>>>> +def x86_subreg_32bit : PatLeaf<(i32 3)>;
>>>>>>> +
>>>>>>> def : SubRegSet<1, [AX, CX, DX, BX, SP, BP, SI, DI,
>>>>>>> R8W, R9W, R10W, R11W, R12W, R13W, R14W,
>>>>>>> R15W],
>>>>>>> [AL, CL, DL, BL, SPL, BPL, SIL, DIL,
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>
> _______________________________________________
> 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/20080311/f07e141b/attachment.html>
More information about the llvm-commits
mailing list