- User Since
- Feb 21 2018, 6:39 AM (134 w, 4 d)
Fri, Sep 18
Allow patterns to explicitly ask to look through copies.
Tue, Sep 15
Mon, Sep 14
Fri, Sep 11
Move change in IRTranslator in another patch, since effects of that change can only be seen when function attributes are inspected during translation of a function that was not first in input file.
Move check for NoNaNsFPMath in isKnownNeverSNaN.
Reduce number of tests, only keep characteristic ones that will be updated when we add some combines and improvements to legalizer. Later switch to existing test in sdag that also checks for pattern commutes.
Add assert for StoreIdx.
Thu, Sep 10
Factor string generation of operand names into function.
min3/max3 patterns are handled in combiner, inducing med3 patterns with constants. Patch imports med3 isel patterns: min(max(a, b), max(min(a, b), c)) but they need some combines/legalize fixes to be selected. From new imports only V_FRACT can be selected at the moment.
With G_FCANONICALIZE out of the way, we can now select some of the med3 patterns that were imported in D87351.
Wed, Sep 9
Add more verbose comments, and switch to std::array as container for operands.
Show how this emitter change affects isel, and update tablegen tests.
Add additional checks for complex suboperands for test added in D57980. Neither tablegen nor sdag have check for such pattern and it looks like an error to me (there is no way for tablegen to know that some c++ code that generates two operands will generate same operand x (first out operand) from different input operands - these are operand 1 and 2 of G_ADD instruction). Also, if I checked correctly, there were no patterns like that in llvm upstream. Skip such patterns anyway in GlobalIselEmitter.
Tue, Sep 8
Move support for predicate code that uses operands to a separate patch.
Fri, Sep 4
Attempt to teach emitter to collect operands that predicate with 'let PredicateCodeUsesOperands = 1' requires.
Aug 20 2020
Aug 17 2020
Aug 10 2020
Aug 7 2020
Force promotion to 32-bit first when subtarget doesn't have 16-bit instruction.
Addressed review comments.
Aug 6 2020
Switch to custom lowering and update to match changes in dag custom lowering for frem (and use same lowering for s16 also).
@hans, could you please commit this patch for 11.x release?
Aug 3 2020
might be worth to include this also for the 11.x release.
What is the procedure for that?
Remove else branch.
Jul 24 2020
Would it make more sense for narrow scalar to widen to the next multiple of 32 itself?
Probably yes, at least for add, sub and mul. It could calculate required scalar size and call widenScalar instead on reporting UnableToLegalize.
I am not so sure if this would be correct in general, maybe some opcodes prefer next-power-of-2 instead of multiple of NarrowSize?
Jul 23 2020
Jul 22 2020
Preserve flags, and use G_INTRINSIC_TRUNC.
Jul 21 2020
This update also simplifies f16 -> i64 on subtargets without has16BitInsts().
Such targets immediately promote f16 to f32 whenever they encounter f16 def using fp16_to_fp node. Recognize fp16_to_fp input to f32 to i64 and do the same thing as for f16 to i64 conversion. This gives similar(small difference for f16 vectors) results for subtargets with or without has16BitInsts() since f16->i32 gets selected like f16->f32->i32.
Update tests with more detailed checks.
Jul 20 2020
Context was missing.
Split G_FPEXT in legalizer. This could also be widenScalar for TypeIndex == 1.
Jul 17 2020
This might be narrowScalar on TypeIndex==0 but it requires that s16 is at TypeIndex==1 thus I used custom legalize.
Jul 16 2020
Jul 15 2020
Remove tests with preassigned banks, use icmp to produce vcc freeze. Add liveins to functions that didn't have them.
Jul 13 2020
Jul 10 2020
Move isValid check on top.
Jul 9 2020
Jul 8 2020
Jul 7 2020
Add a few sgpr,agpr and vcc tests similar to ones from regbankselect-copy.mir. Original tests were from legalize-freeze.mir
Jul 6 2020
This fixes assert and makes this test mentioned in D82651 to fallback for aarch64.
This seem to have different handling on different targets. I don't know what is the best way to handle this since it looks to me that custom handling has to be done in different places
Just adding same flag and register as MatchedOperand works for this example but from this comment
Jul 3 2020
I see. I expected that reg class was already determined when previous operand was processed. I will take a look, first operand should have probably asked TargetRegisterInfo for PointerRegClass.
Jul 2 2020
Jul 1 2020
Jun 30 2020
Jun 29 2020
Replace assert with isel fail.
Added tests for matching constraints that involve sgpr. Also added one more test file with comparison between 'register class constraint' and 'matching constraint' in final asm output.