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