thr3ads.net - llvm dev - [LLVMdev] Making Sense of ISel DAG Output [Oct 2008]

If this information is useful, please help other people find it:
Share via:

David Greene

2008-Oct-02 21:19 UTC

[LLVMdev] Making Sense of ISel DAG Output

On Thursday 02 October 2008 12:42, David Greene wrote:
> But let's say you _could_ write such a pattern (because I can).  The
input
> DAG looks like this:
>
>             0x391a220: <multiple use>
>           0x391c970: v2f64 = scalar_to_vector 0x391a220 srcLineNum= 10
>             0x391ac10: <multiple use>
>           0x391c8b0: v2f64 = scalar_to_vector 0x391ac10 srcLineNum= 10
>           0x3927b10: <multiple use>
>         0x3923100: v2f64 = vector_shuffle 0x391c970, 0x391c8b0,
> 0x3927b10<0,2> srcLineNum= 10
>
> The code that gets produced looks like this:
>
> 	%reg1071<def> = MOVSD2PDrm %reg1026, 8, %reg1065, 4294967288,
Mem:LD(8,8)
> [r66428 + 0]LD(8,8) [r78427 + 0]	 ; srcLine 10
> 	%reg1072<def> = MOVSD2PDrm %reg1026, 8, %reg1065, 4294967288,
Mem:LD(8,8)
> [r66428 + 0]LD(8,8) [r78427 + 0]	 ; srcLine 10
> 	%reg1073<def> = SHUFPDrri %reg1071, %reg1072, 0	 ; srcLine 10
Actrually, it's worse than this.  I wanted to check to make sure something 
else wasn't causing the problem but it appears to come from isel.  The full 
output for the DAG looks like this:

	%reg1059<def> = MOVSX64rm32 %reg1033, 1, %reg0, 4, Mem:LD(4,4) [tmp163 + 
0]	 ; srcLine 10
	%reg1060<def> = MOVSDrm %reg1026, 8, %reg1059, 4294967288, Mem:LD(8,8) 
[r45154 + 0]	 ; srcLine 10
	%reg1061<def> = MOVSX64rm32 %reg1033, 1, %reg0, 0, Mem:LD(4,4) [iv.161162
+
0]	 ; srcLine 10
	%reg1062<def> = MOVSDrm %reg1026, 8, %reg1061, 4294967288, Mem:LD(8,8) 
[r30158 + 0]	 ; srcLine 10
	%reg1063<def> = MOVSD2PDrm %reg1026, 8, %reg1059, 4294967288, Mem:LD(8,8)
[r30158 + 0]LD(8,8) [r45154 + 0]	 ; srcLine 10
	%reg1064<def> = MOVSD2PDrm %reg1026, 8, %reg1059, 4294967288, Mem:LD(8,8)
[r30158 + 0]LD(8,8) [r45154 + 0]	 ; srcLine 10
	%reg1065<def> = SHUFPDrri %reg1063, %reg1064, 0	 ; srcLine 10

Where the <bleep> are these extra dead MOVSDrms coming from?  Note that
the
extra MOVSDrms at least seem to use the correct addresses.

                                                   -Dave

Haohui Mai

2008-Oct-02 22:16 UTC

head link

[LLVMdev] Compliation broken

Hi all,

The current repository (revision 56968.) does not compile on my Linux  
box (with GCC 3.4.6):

X86TargetAsmInfo.cpp:41: error: duplicate explicit instantiation of  
`bool  
llvm::X86TargetAsmInfo<BaseTAI>::ExpandInlineAsm(llvm::CallInst*)  
const [with BaseTAI = llvm::TargetAsmInfo]'
X86TargetAsmInfo.cpp:43: error: duplicate explicit instantiation of  
`bool llvm::X86TargetAsmInfo<BaseTAI>::LowerToBSwap(llvm::CallInst*)  
const [with BaseTAI = llvm::TargetAsmInfo]'


I'm not seeing this issue on my Macbook with GCC 4.0.1.

And it seems that there is a file missing at llvm/tools/llvmc2/ 
plugins. The Makefile  in llvm/tools/llvmc2/plugins/Base says:

LLVMC_PLUGIN = Base

include ../Makefile.common

In which ../Makefile.common is missing.

I'd be very appreciated if somebody could fix these issues.

Thank you very much!

Best,

Haohui

Óscar Fuentes

2008-Oct-02 23:03 UTC

head link

[LLVMdev] Compliation broken

Haohui Mai <haohui.mai at gmail.com> writes:
> Hi all,
>
> The current repository (revision 56968.) does not compile on my Linux  
> box (with GCC 3.4.6):
>
> X86TargetAsmInfo.cpp:41: error: duplicate explicit instantiation of  
> `bool  
> llvm::X86TargetAsmInfo<BaseTAI>::ExpandInlineAsm(llvm::CallInst*)  
> const [with BaseTAI = llvm::TargetAsmInfo]'
> X86TargetAsmInfo.cpp:43: error: duplicate explicit instantiation of  
> `bool llvm::X86TargetAsmInfo<BaseTAI>::LowerToBSwap(llvm::CallInst*)
> const [with BaseTAI = llvm::TargetAsmInfo]'
In

http://llvm.org/bugs/show_bug.cgi?id=2846

a user reports the same problem while using the CMake build system, and
then says that it compiles okay with configure && make. Now you say that
it fails with configure && make.

OTOH, as a comment on that bug report says, gcc 3.4.x is known to be
broken on AMD64:

http://llvm.org/docs/GettingStarted.html#brokengcc
> I'm not seeing this issue on my Macbook with GCC 4.0.1.
>
> And it seems that there is a file missing at llvm/tools/llvmc2/ 
> plugins. The Makefile  in llvm/tools/llvmc2/plugins/Base says:
>
> LLVMC_PLUGIN = Base
>
> include ../Makefile.common
>
> In which ../Makefile.common is missing.
There was a commit related to this very recently. Update and try again.

-- 
Oscar

Óscar Fuentes

2008-Oct-02 23:04 UTC

head link

[LLVMdev] Compliation broken

Haohui Mai <haohui.mai at gmail.com> writes:
> Hi all,
>
> The current repository (revision 56968.) does not compile on my Linux  
> box (with GCC 3.4.6):
>
> X86TargetAsmInfo.cpp:41: error: duplicate explicit instantiation of  
> `bool  
> llvm::X86TargetAsmInfo<BaseTAI>::ExpandInlineAsm(llvm::CallInst*)  
> const [with BaseTAI = llvm::TargetAsmInfo]'
> X86TargetAsmInfo.cpp:43: error: duplicate explicit instantiation of  
> `bool llvm::X86TargetAsmInfo<BaseTAI>::LowerToBSwap(llvm::CallInst*)
> const [with BaseTAI = llvm::TargetAsmInfo]'
In

http://llvm.org/bugs/show_bug.cgi?id=2846

a user reports the same problem while using the CMake build system, and
then says that it compiles okay with configure && make. Now you say that
it fails with configure && make.

OTOH, as a comment on that bug report says, gcc 3.4.x is known to be
broken on AMD64:

http://llvm.org/docs/GettingStarted.html#brokengcc
> I'm not seeing this issue on my Macbook with GCC 4.0.1.
>
> And it seems that there is a file missing at llvm/tools/llvmc2/ 
> plugins. The Makefile  in llvm/tools/llvmc2/plugins/Base says:
>
> LLVMC_PLUGIN = Base
>
> include ../Makefile.common
>
> In which ../Makefile.common is missing.
There was a commit related to this very recently. Update and try again.

-- 
Oscar

Dan Gohman

2008-Oct-03 00:32 UTC

head link

[LLVMdev] Making Sense of ISel DAG Output

On Oct 2, 2008, at 2:19 PM, David Greene wrote:
> On Thursday 02 October 2008 12:42, David Greene wrote:
>
>> But let's say you _could_ write such a pattern (because I can).   
>> The input
>> DAG looks like this:
>>
>>            0x391a220: <multiple use>
>>          0x391c970: v2f64 = scalar_to_vector 0x391a220 srcLineNum= 10
>>            0x391ac10: <multiple use>
>>          0x391c8b0: v2f64 = scalar_to_vector 0x391ac10 srcLineNum= 10
>>          0x3927b10: <multiple use>
>>        0x3923100: v2f64 = vector_shuffle 0x391c970, 0x391c8b0,
>> 0x3927b10<0,2> srcLineNum= 10
>>
>> The code that gets produced looks like this:
>>
>> 	%reg1071<def> = MOVSD2PDrm %reg1026, 8, %reg1065, 4294967288,  
>> Mem:LD(8,8)
>> [r66428 + 0]LD(8,8) [r78427 + 0]	 ; srcLine 10
>> 	%reg1072<def> = MOVSD2PDrm %reg1026, 8, %reg1065, 4294967288,  
>> Mem:LD(8,8)
>> [r66428 + 0]LD(8,8) [r78427 + 0]	 ; srcLine 10
>> 	%reg1073<def> = SHUFPDrri %reg1071, %reg1072, 0	 ; srcLine 10
>
> Actrually, it's worse than this.  I wanted to check to make sure  
> something
> else wasn't causing the problem but it appears to come from isel.   
> The full
> output for the DAG looks like this:
>
> 	%reg1059<def> = MOVSX64rm32 %reg1033, 1, %reg0, 4, Mem:LD(4,4)  
> [tmp163 +
> 0]	 ; srcLine 10
> 	%reg1060<def> = MOVSDrm %reg1026, 8, %reg1059, 4294967288,  
> Mem:LD(8,8)
> [r45154 + 0]	 ; srcLine 10
> 	%reg1061<def> = MOVSX64rm32 %reg1033, 1, %reg0, 0, Mem:LD(4,4) [iv. 
> 161162 +
> 0]	 ; srcLine 10
> 	%reg1062<def> = MOVSDrm %reg1026, 8, %reg1061, 4294967288,  
> Mem:LD(8,8)
> [r30158 + 0]	 ; srcLine 10
> 	%reg1063<def> = MOVSD2PDrm %reg1026, 8, %reg1059, 4294967288,  
> Mem:LD(8,8)
> [r30158 + 0]LD(8,8) [r45154 + 0]	 ; srcLine 10
> 	%reg1064<def> = MOVSD2PDrm %reg1026, 8, %reg1059, 4294967288,  
> Mem:LD(8,8)
> [r30158 + 0]LD(8,8) [r45154 + 0]	 ; srcLine 10
> 	%reg1065<def> = SHUFPDrri %reg1063, %reg1064, 0	 ; srcLine 10
>
> Where the <bleep> are these extra dead MOVSDrms coming from?  Note  
> that the
> extra MOVSDrms at least seem to use the correct addresses.
Looking at your dump() output above, it looks like the pre-selection
loads have multiple uses, so even though you've managed to match a
larger pattern that incorporates them, they still need to exist to
satisfy some other users.

Dan

David Greene

2008-Oct-03 16:10 UTC

head link

[LLVMdev] Making Sense of ISel DAG Output

On Thursday 02 October 2008 19:32, Dan Gohman wrote:
> Looking at your dump() output above, it looks like the pre-selection
> loads have multiple uses, so even though you've managed to match a
> larger pattern that incorporates them, they still need to exist to
> satisfy some other users.
Yes, I looked at that too.  It looks like these other uses end up being
chains to TokenFactor nodes that don't go anywhere.  They're really,
truly,
dead.  Who is supposed to clean those up?

                                           -Dave

David Greene

2008-Oct-03 20:46 UTC

head link

[LLVMdev] Making Sense of ISel DAG Output

On Thursday 02 October 2008 16:19, David Greene wrote:
> 	%reg1059<def> = MOVSX64rm32 %reg1033, 1, %reg0, 4, Mem:LD(4,4)
[tmp163 +
> 0]	 ; srcLine 10
> 	%reg1060<def> = MOVSDrm %reg1026, 8, %reg1059, 4294967288,
Mem:LD(8,8)
> [r45154 + 0]	 ; srcLine 10
> 	%reg1061<def> = MOVSX64rm32 %reg1033, 1, %reg0, 0, Mem:LD(4,4)
[iv.161162
> + 0]	 ; srcLine 10
> 	%reg1062<def> = MOVSDrm %reg1026, 8, %reg1061, 4294967288,
Mem:LD(8,8)
> [r30158 + 0]	 ; srcLine 10
> 	%reg1063<def> = MOVSD2PDrm %reg1026, 8, %reg1059, 4294967288,
Mem:LD(8,8)
> [r30158 + 0]LD(8,8) [r45154 + 0]	 ; srcLine 10
> 	%reg1064<def> = MOVSD2PDrm %reg1026, 8, %reg1059, 4294967288,
Mem:LD(8,8)
> [r30158 + 0]LD(8,8) [r45154 + 0]	 ; srcLine 10
> 	%reg1065<def> = SHUFPDrri %reg1063, %reg1064, 0	 ; srcLine 10
>
> Where the <bleep> are these extra dead MOVSDrms coming from?  Note
that the
> extra MOVSDrms at least seem to use the correct addresses.
Ok, I figured out why I'm not getting the correct addresses for the 
MOVSD2PDrms.  It's another tblgen bug I have to patch.  So I'll fix that
and
see what happens.

                                                        -Dave

Reasonably Related Threads

Search for more seemingly similar threads

llvm dev - Oct 2008 - [LLVMdev] Making Sense of ISel DAG Output

[LLVMdev] Making Sense of ISel DAG Output

[LLVMdev] Compliation broken

[LLVMdev] Compliation broken

[LLVMdev] Compliation broken

[LLVMdev] Making Sense of ISel DAG Output

[LLVMdev] Making Sense of ISel DAG Output

[LLVMdev] Making Sense of ISel DAG Output

Reasonably Related Threads