Displaying 4 results from an estimated 4 matches for "g_select".
2018 Sep 14
2
[GlobalISel][MIPS] Legality and instruction combining
Hi Daniel,
On 13.09.2018. 19:32, Daniel Sanders wrote:
> Could you clarify what you mean here? The new legalizer info can
> define this with:
> getActionDefinitionsBuilder(G_SELECT).clampScalar(1, s32, s32)
> so I'm guessing you mean that code to mutate the G_SELECT is currently
> missing
Yes, LegalizerHelper::widenScalar widens only TypeIdx==0, it doesn't do
that for TypeIdx==1. Is it intentionally implemented this way?
>> b) Is the plan to sometimes le...
2018 Sep 13
2
[GlobalISel][MIPS] Legality and instruction combining
...ossible combining of instructions and artifacts in pre/post legalizer combiner or elsewhere (e.g. in some sort of instruction-select patterns).
I look at legality as "If generic instruction can be selected into machine instruction, it is legal".
For example, let's look at G_ICMP and G_SELECT. In llvm IR type of result of icmp is always i1, and test argument (type 1) in select is also i1.
Here is an .ll example:
define i32 @f(i32 %a, i32 %b, i32 %c, i32 %d) {
entry:
%cmp = icmp slt i32 %a, %b
%cond = select i1 %cmp, i32 %d, i32 %c
ret i32 %cond
}
and corresponding MIR snippet:...
2018 Sep 21
2
[GlobalISel] Legalize generic instructions that also depend on type of scalar, not only scalar size
...has 64 bit floating point instructions, while i64 instructions
have to be emulated with i32 instructions. This means that G_LOAD should
be custom legalized for s64 integer value, and be legal for s64 floating
point value. There are also other generic instructions with the same
problem: G_STORE, G_SELECT, G_EXTRACT, and G_INSERT.
There are also other configurations where integer and floating point
instructions of the same size are not simultaneously available. This
problem was already addressed here
http://lists.llvm.org/pipermail/llvm-dev/2017-July/114978.html for
G_LOAD/G_STORE.
Legality of...
2019 Sep 27
4
Dealing with boolean values in GlobalISel
...o register banks used for operands that really function as booleans (select/br conditions, compare results, and a few intrinsics). These two banks physically alias the SGPR bank, but contextually function differently than an s1 value from a non-boolean source (e.g. a G_LOAD of s1 or G_TRUNC to s1). G_SELECT (s1 G_LOAD) would be illegal for example without inserting some kind of compare between the load and select boolean use.
The primary problem I’m currently aiming to solve is losing this contextual pseudo-register bank information once an instruction is selected, as a virtual register can only have...