- User Since
- Feb 21 2018, 6:39 AM (99 w, 2 d)
Mon, Jan 13
Fri, Jan 3
G_CONSTANT can already directly have a pointer type, so I don't see a reason that the extra G_INTTOPTR needs to be involved.
When I started this patch I thought the same. nullptr was translated like that some time ago, D44762 changed it to what we have now. NullPtrValue was meant to match IRTranslator's translation of llvm-ir null
Tue, Dec 31
Mon, Dec 30
Buildbot failures depend on compiler used to build clang.
Problem was in order which new MachineInstructions get inserted into MachineFunction.
Generated assembler does the same thing, but regression tests require consistent behavior regardless of compiler used.
return B.buildOr(Dst, B.buildLShr(Ty, B.buildAnd(Ty, Src, MaskLoNTo0), C_N), B.buildAnd(Ty, B.buildShl(Ty, Src, C_N), MaskLoNTo0));
it is important which method was executed first since they insert MachineInstructions into MachineFunction. Order of execution:
B.buildAnd(Ty, B.buildShl(Ty, Src, C_N), MaskLoNTo0) B.buildLShr(Ty, B.buildAnd(Ty, Src, MaskLoNTo0), C_N)
Dec 18 2019
Dec 12 2019
This patch needs only bswap, I just checked and it worked fine for me, what was the error?
Forgot to run regression tests for amd.
Dec 11 2019
Dec 9 2019
Rebase and ping.
Dec 2 2019
Attempt to switch to insertelt and extractelt for mips. Simplified a few lines.
Nov 29 2019
Nov 28 2019
Nov 26 2019
Nov 25 2019
With removed xfail from tests, this looks good to me. I would like to hear if other reviewers have comments.
Nov 22 2019
RegbankSelect doesn't track newly created instruction and I had to set reg bank manually. Here is the patch that sets regbank for newly created COPY instructions.
Nov 15 2019
Nov 14 2019
Since n32 worked before, you could change
It accepts la pseudo instruction on 64-bit arch and just shows a warning.
It accepts la pseudo instruction on arch with 64-bit pointers and just shows a warning.
Nov 13 2019
Nov 12 2019
I don't fully understand G_BUILD_VECTOR_TRUNC. Such opcode does not exist in llvm-ir and as such can only be created in legalizer or later (at the moment at least). The problem here is the context sensitive legality (we still avoid this) along side with type legality. e.g. types might be fine but we still can't select an instructions because vector is built from different virtual registers (so splat is not an option) and we should perform lower. At the current state of legalizer I don't think it is possible to have it legal for type and as such I planned to handle it with custom legalization by either context sensitive select or lower.
Nov 6 2019
Correction from previous comment, tests for SaaAddr and SaadAddr are already present.
Nov 5 2019
Missing test for SaaAddr and SaadAddr.
Nov 4 2019
I have just saw these two asserts that forbid different types of vector scalar and element scalar
Widen scalar change does not trigger asserts since it only changes operand instead of making new instruction. How do we approach this issue then?
Btw, based on G_ZEXTLOAD and G_SEXTLOAD, are G_SEXT_EXTRACT_VECTOR_ELT and G_ZEXT_EXTRACT_VECTOR_ELT a consideration?
They would have different element scalar then vector scalar.
I don't understand the motivation.
The vector element and insert element type need to match, but it appears there's a missing verifier check
This is definitely true for llvm-ir insertelement and extractvalue.
But SDAG nodes ISD::INSERT_VECTOR_ELT and ISD::EXTRACT_VECTOR_ELT don't follow this,
Mips uses DAGTypeLegalizer::PromoteIntegerResult for i8 and i16 and promotes them to i32 leaving vector scalar type unchanged.
In .td file element being inserted/extracted has i32 operand type (for i8, i16 and i32) and instruction is selected based on vector type (v16i8, v8i16, v4i32).
D69513 goes first, following what SDAG does
%8:_(<16 x s8>) = G_INSERT_VECTOR_ELT %6:_, %7:_(s8), %5:_(s32)
should change only insert elt scalar type, and leave vector scalar type as is
%8:_(<16 x s8>) = G_INSERT_VECTOR_ELT %6:_, %7:_(s32), %5:_(s32) (in function: insert_i8)
insert instruction is selected based on vector type, inserted scalar is always i32 (i32 or i64 for mips64)
Nov 1 2019
Address review comments.
Oct 31 2019
Oct 28 2019
Oct 25 2019
Oct 24 2019
Fix names of test files, be more specific in summary about llvm.fabs.* type since MIPS can generate scalar llvm.fabs.* but cannot generate vector llvm.fabs.*.
Oct 23 2019
Oct 22 2019
Oct 18 2019
RegClassOrRegBank is a PointerUnion<const TargetRegisterClass *, const RegisterBank *>.
Plain nullptr is a const TargetRegisterClass * (the first template type)
but static_cast<RegisterBank *>(nullptr) is nullptr of const RegisterBank * type.
Oct 17 2019
Oct 16 2019
Addressed review comments.
Will wait for conclusion of D68946 before commit, to see what to do with mir tests for legalizer.
Fix flags in tests.
Oct 15 2019
Add dedicated test for MIParser.
Oct 14 2019
Motivation is having same behavior for GlobalISel legalizer tests for -stop-after=legalizer (llvm-ir input) and -run-pass=legalizer (mir input created from output of same llvm-ir input by pass before legalizer), later has few extra COPY instructions.
Mips has builtin functions (not available as generic opcode) that correspond to a machine instruction, and as such can be selected during legalization.
When selected, register classes also have to be constrained because other passes leave target specific instructions as they are.
Such builtin functions turned to intrinsic and are handled in MipsLegalizerInfo::legalizeIntrinsic.