[LLVMdev] How to handle predicate registers which can also work inverted way.
Jakob Stoklund Olesen
stoklund at 2pi.dk
Wed May 26 09:23:56 PDT 2010
On May 26, 2010, at 12:08 AM, Heikki Kultala wrote:
> In our architecture (TCE) we have predicate registers, not flags.
The old IA64 backend had a similar architecture. The code was removed because nobody was maintaining it.
> But our predicates work in a way that in the predicated instruction do not contain only the predicate register,
> but a predicate register and boolean value pair, the boolean value stating if the instruction is to be executed
> only if the register is true(normal behavior of predicate regs) or only if the predicate reg is false("inverted behaviour")
>
> So, for eample if we have a machine without "not equal"(ne) operation and we have a code where we would have an
> "ne" comparison followed by predicated jump, it is possible to do this with "eq" comparison followed by a inverted-predicate predicated jump.
The Blackfin processor does the same. It has only half of the SETCC conditions, and "if cc jump" and "if !cc jump" instructions.
> The problem is that we have not found a way to use those inverted guard, we don't know how to create the patterns/register classes which would allow us to do this, and currently we just do extra xor 1 operation to get a positive boolean value, "emulate ne with eq and xor" and then jump with normal predicate. This makes the code run slower.
>
> One idea is to introduce our boolean register twice to llvm, and make them aliases to each others, and then just create double patterns for all comparison operations, so that "eq" could be selected as "eq" to normal predicate reg class, or "ne" to inverted predicate class, and then having two predicated jump instructions, one reading the value from ordinary predicate reg, another from inverted predicate reg, creating usage of the inverted predicate.
This is exactly what the Blackfin backend does. Look at the CC and NCC registers.
> Could this work? Is it allowed to have multiple register classes working as predicate register class in llvm? and would the aliasing work without problems?
The aliasing should not cause any problems.
You may run into issues with having legal i1 registers. The IA64 backend never fully worked, causing weird DAG combiner assertions on i1 arithmetic. Aim to fix the DAG combiner - it should work.
/jakob
More information about the llvm-dev
mailing list