[LLVMdev] Problems with DAG Combiner

[Stripf, Timo]

I converted now my back-end with legal i1 lowering to the 2.6 branch and my original problem with the DAG combiner didn't occur any more and seems to be fixed. setOperationAction(ISD::OR, MVT::i1, Promote) also works fine for logical operations. 

> What is your SetCCResultType now?

I changed SetCCResultType to return MVT::i1 type. 

> Can you compile the CodeGen/Blackfin/basic-i1.ll test case? I never  
> got that one working with legal i1. The IA64 back-end couldn't compile  
> it either.

No, I was not able to compile your basic-i1.ll test case but I think it is no big deal to add the missing Promote or Expand code for these operations. "add i1" / "sub i1" can be changed to "xor i1", "mul i1" to "and i1". I think div/rem operations must be promoted.

> I hate to scope-creep your research, but I would be very interested in  
> an analysis of native i1 operations versus promotions. Are you  
> planning an ISA version with built-in i1 AND/OR/XOR?

I've generated a back-end with built-in i1 AND/OR/XOR operations and compared the results against a back-end without these operations. Atm I don't have many applications I can test. I've one application that runs only the CABAC part of H.264 and thereby i1 AND/OR/XOR operations decrease the number of executed operations by 0.2% on a behavioural instruction-set simulator. I used gcc front-end, maybe clang uses more i1 instructions. 

Also the AND/OR/XOR promotion is not perfect. It produces the following code:

	ZEXT %r4, %e0
	ZEXT %r0, %e1 
	OR %r0, %r0, %r4
	AND %r2, %r0, 1

for i1 or operations when the trunc is eliminated. The last AND is needless. The lowering doesn't know that any_extend is selected to a zero_extend opcode later.

Another problem came up when I tried to promote constant i1 values to i32. It required a custom legalization but later the instruction selector found i1 constants. So I suspect that DAG combiner reintroduced i1 constants. I gave up and added a related instruction to the architecture.

Kind regards
Timo Stripf

-----Ursprüngliche Nachricht-----
Von: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] 
Gesendet: Montag, 24. August 2009 07:11
An: Stripf, Timo
Cc: LLVM Developers Mailing List
Betreff: Re: [LLVMdev] Problems with DAG Combiner


On 24/08/2009, at 01.19, Stripf, Timo wrote:
>
> I had also a lot of problems to get the i1 operations working. E.g.  
> I had to override the getSetCCResultType to get is working and for  
> ADDE/ADDC the i1 target registers are hardcoded.

What is your SetCCResultType now?

Can you compile the CodeGen/Blackfin/basic-i1.ll test case? I never  
got that one working with legal i1. The IA64 back-end couldn't compile  
it either.

> I'm writing the back-end to research the influence of several ISA  
> characteristics on the processor performance. Large parts of my back- 
> end are automatically generated by a general description. So I'm  
> very interested in keeping the DAG as realistic as possible.

I hate to scope-creep your research, but I would be very interested in  
an analysis of native i1 operations versus promotions. Are you  
planning an ISA version with built-in i1 AND/OR/XOR?

>> I don't think you have to write custom lowering code to get the
>> behaviour you want. Have you tried this:
>>
>>   setOperationAction(ISD::OR, MVT::i1, Promote);
>
> I tried Promote and Expand but on the 2.5 code base it is not  
> implemented.

Yeah, you definitely need 2.6. Blackfin has  
setOperationAction(ISD::OR, MVT::i16, Promote), and it took a few bug  
fixes to get that working.

/jakob