User Details
- User Since
- Mar 5 2014, 4:23 PM (472 w, 3 d)
Thu, Mar 23
llvm/test/CodeGen/Mips/ removed here: https://reviews.llvm.org/rG805f51f9fedf90d2aa0ad46c61cb4c9c0c5bcfe9
Wed, Mar 22
https://lists.riscv.org/g/sig-toolchains/message/548 has a proposal where X27 is one of the registers.
Tue, Mar 21
Removed several testcases related to 'mips.*-linux-android'
Removed testcases.
Mon, Mar 20
Thanks for putting the patch.
ping @StephenFan
Fri, Mar 17
Platforms like Android reserve a register x18(for AArch64). There was a patch for RISC-V that also reserved x18 for shadow callstack. https://reviews.llvm.org/D14599, https://reviews.llvm.org/D143355
Thu, Mar 16
Tue, Mar 14
Folded D145979 here
I'll fold this to D145999.
Mon, Mar 13
Moved the testcase as suggested by @samitolvanen
Are there possible optimizations which can be implemented to reduce the code-size impact of this change? I'm wondering if this patch adds the checks conservatively to all instances where stack check could potentially, but not necessarily, be missed/useful?
This patch is needed for zbb support as per: https://lore.kernel.org/all/20230117122447.y6tdsmsxqdwf76ri@orel/
Tue, Mar 7
Mon, Feb 27
Can this patch also convert this one to strlen? gcc is able to recognize this idiom: https://godbolt.org/z/7ra1ErqKK
@joshua-arch1 i can land this on your behalf if you think this is good to go.
Can we land this patch. I think this is quite useful at -Oz
LGTM, i'll let the code owners make the final call. Thanks for working on this.
Feb 10 2023
this patch is still better than the status quo where it sounds like we're generating incorrect code and might be reasonable stop-gap.
Feb 9 2023
LGTM, thanks for putting this patch.
Also cc: @craig.topper
Thanks for doing this. LGTM, defer to code owners for approval.
Feb 7 2023
Updated the failing testcase.
reopening to update the failing testcase.
Feb 6 2023
thanks for reverting it. i'll take care of the test failure.
Feb 1 2023
@joshua-arch1 can you share your email such that I can commit this with proper author info? Feel free to ping me directly on discord: Aditya Kumar#9439
Jan 29 2023
Link to llvm presentation for reference: https://llvm.org/devmtg/2019-04/slides/TechTalk-Kruppe-Espasa-RISC-V_Vectors_and_LLVM.pdf
Jan 27 2023
cc: @jrtc27 anything you still want addressed?
Is it okay to merge this patch?
Jan 23 2023
if this patch helps make progress for some folks, i think it is reasonable to merge this one as well. @nickdesaulniers do you have any objections to merging this patch?
Jan 9 2023
Nov 26 2022
Sep 22 2022
Any interest in landing it?
Sep 8 2022
LGTM
is it okay to merge this patch or are there pending dependencies?
Sep 3 2022
ping: do we plan to merge this patch?
Aug 26 2022
More changes were needed to make it work on my machine. I've added them in a separate diff: https://reviews.llvm.org/D132523
LGTM
Aug 24 2022
My understanding is that a basic block with a PHI node should have first instruction as PHI
Aug 23 2022
Make it git compatible.
Added all the changes
Adding more fixes.
nit: please edit the summary with
// (X + C2) | C // (X + C2) ^ C // (X + C2) & C
I agree with @eli.friedman that decomposing multiply into two separate instructions may not be profitable.
Even when latency of multiply is high, having two instructions in the pipeline adds complexity (dependencies, re-ordering, retiring etc).
Is there another induction variable optimization pass that this can be merged with?
with arc diff
Not working either. Do I have to reboot the machine/restart a service ?
Machine type:
lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.1 LTS Release: 22.04 Codename: jammy
Aug 22 2022
neat! it'll be great if for loop bounds that don't overflow and can be inferred at compile time, the first version just get DCE'd.
Thanks for enabling this!
Aug 21 2022
Aug 10 2022
Aug 5 2022
Aug 1 2022
a / 5, and a%10 etc.
Looks pretty interesting. I'm curious if there is a popular workload/benchmark that would improve with this patch?
Jul 28 2022
We usually provide a runtime library for specialized functionalities like this. Are such division operations common enough to benefit from compiler generated code?
FYI, all the tests in this patch are already handled with the current licm. Do we still need this patch?