[LLVMdev] Problems with DAG Combiner

[Jakob Stoklund Olesen]

Stripf, Timo wrote:
> 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.

Excellent.

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

Yeah. div/rem can probably just return the first argument since division
by zero is undefined.

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

Great, thanks for doing this.

Since C arithmetic is always promoted to at least int, I wouldn't expect
a C frontend to produce any i1 arithmetic. It could appear as a result
of optimizations and in the DAG combiner, though.

It looks like i1 operations are not that useful, but I can think of a
few cases where they vcould help performance. For instance "if (a<b &&
b<c)" would benefit from using only one conditional branch on a platform
with weak branch prediction.

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

Hey, that's cheating! The rest of us don't get to do that, you know. :-)

/jakob