llvm dev - May 2010 - [LLVMdev] How to handle predicate registers which can also work inverted way.

In our architecture (TCE) we have predicate registers, not flags.

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

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?


And if this does not work, could someone give idea about some other solution
that might work?

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