- User Since
- Jun 11 2021, 5:40 AM (67 w, 6 d)
Fri, Sep 9
Now appears to produce functionally correct code.
Feature fully deprecated in D132060
Wed, Sep 7
Mon, Sep 5
rebased onto main
Fri, Sep 2
Combined overloads for both updateReduction and getReductionInChain into two singlular functions with optional parameters
Thu, Sep 1
Aug 25 2022
Added test for kind=8
Aug 24 2022
Aug 23 2022
Aug 19 2022
rebased onto more recent base.
Aug 11 2022
Aug 9 2022
I've re-ran clang-format on OpenMP.cpp, hopefully that fixes the problem!
Aug 8 2022
Aug 5 2022
Added comment to getOperationIdentity() to explain it's usage.
Renamed "name" to "reductionOpName" for clarity.
Aug 4 2022
Added comment explaining getReductionInChain, renamed obscure/incorrect variables
rebased onto D131161
Aug 1 2022
Created getReductionInitValue(), and made getOperationIdentity static
Jul 29 2022
I moved the code for getting the identity to a seperate function as suggested.
Jul 27 2022
Jul 26 2022
Jul 22 2022
After pushing to main, this patch cause a buildbot failure as CLANG_TABLEGEN_EXE could not be found.
Jul 21 2022
Jul 20 2022
Jul 19 2022
Edited summary to be more clear.
Jul 15 2022
Jul 13 2022
Fixed typo 'exectued' to 'executed'
Updated comment to better explain where the paths are relative to.
Ah, I meant it as from the binary working directory, as this file exists in both src and bin, and is copied over at build time, before being ran.
The comment itself is probably not needed, but without it, 'Dialect/FIRLangref.md' might seem like a non-existant file.
Jul 11 2022
Rebased onto main.
I don't believe the path needs to be at the top here? I may be wrong but I think they're mainly for manual execution, This script should only realistically be ran as part of the HTML auto-generation process.
I've added a comment to the top of the file to explain it's purpose at least, I think that should be sufficient in this case.
I've moved the dependency inside the custom_target declaration, it should resolve the issue of dependency ordering.
Ah, I must've forgotten about that problem,
Jul 8 2022
Reworked CreateFIRLangRef.py to better fit pythons standards based upon internal review.
Jul 6 2022
Jul 1 2022
Expanded comments around copying files.
Jun 29 2022
Changed summary to include problem with incorrect formatting.
Removed copying of FIRLangRef to source.
Jun 27 2022
Aug 17 2021
Aug 13 2021
Aug 12 2021
Added checks for MaxVScale > 0
Changed getMaxNumElemenets() to take Function* instead of Instruction*
Fixed clang-tidy warning
Aug 4 2021
Added check for MaxVScale > 0
Aug 3 2021
Yeah, I think it definitely makes sense to have it put into the LLVM13 release
I'm looking into it now, hopefully I'll have a fix for it soon.
Aug 2 2021
I did recently encounter a bug from binop matching here https://reviews.llvm.org/D105978 I don't think these cases are related, but it might be worth having a quick check just to rule it out for definite?
Jul 30 2021
Jul 27 2021
Rebased onto main, updated newly added AArch64 getMaxVScale usages to use IR attribute instead
Jul 26 2021
Changed bitshift to Log2_32
Added getVScaleRange interface to TargetInfo and removed related AArch64 specific code from CodeGenFunction.cpp
Jul 23 2021
I forgot to check this patch with all targets before putting it for review
Two none AARch64 tests were affected, I've updated them to work now and the output seems to be as expected
Jul 22 2021
Removed changes to RiscV code
Added check that target isAArch64 before adding default value vscale_range attribute
Fixed lint issues
Added comment stating that not checking for one use is intentional
Jul 21 2021
Added check for vscale_range attribute before optimisation
If the attribute isn't present, or if the maximum value exceeds the bitwidth of the original instrinsic, the optimization is skipped