The sea was angry that day, my friends - like an old man trying to send back soup in a deli.
- User Since
- Sep 9 2013, 3:45 AM (406 w, 15 h)
Thu, Jun 17
Shouldn't we also have verifier checks for these requirements in the statically known cases?
Wed, Jun 16
Compile time seems to be noise, since this the new combine only runs in some cases where the unmerge combine fails, which is rare in most code. I would have liked to use it as the first-attempt combine for unmerge, but AMDGPU just wound up getting into a legalization loop (I think that's a problem with AMDGPU rather than the combine itself).
I am a little bit surprised by the long sequences that we generate now in certain case. What is the reason for that? (See inline comment for a highlight of what I am talking about.)
Remove commented out code.
Tue, Jun 15
Fri, Jun 11
Thu, Jun 10
Mon, Jun 7
Fri, Jun 4
You can add a hook to TargetLoweringInfo so that only targets which want to use big-endian in GlobalISel can enable it (just M68k for now). Then check this hook, if it false then do the current fallback code.
Thu, Jun 3
Tue, Jun 1
Fri, May 28
LGTM with minor nits addressed, thanks.
Thu, May 27
Wed, May 26
Tue, May 25
May 20 2021
May 19 2021
This doesn’t seem to happen on Darwin, so it’s a surprise that it’s just being noticed now. Either way makes sense to disable it in a better way.
I don't propose to re-enable the test until it is fixed -- at the moment the test is actively failing for myself and colleagues when running 'lnt runtest nt --test-suite llvm-test-suite'. Is there some other way to inhibit the test?
If so, I propose to do that.
I also worry for a moment in time that there is a window of time where *all* of these generated 'basic correctness tests' are disabled. It seems to me those tests could usefully catch bugs. Can we do better by only inhibiting the failing ones?
Sure. I did report this to Arm on multiple occasions, and as maintainers of the ACLE implementation I think Arm’s proprietary tool chain team should be taking responsibility for this to fix the issue.
May 18 2021
May 17 2021
May 16 2021
Guard this with a TLI check. I think a separate pass to do this is overkill.
May 14 2021
May 13 2021
This seems to have broken the following code for AArch64, could you take a look?
May 12 2021
May 11 2021
@paquette See any issues with this?
May 10 2021
Wow, not running this at all for -Oz? LGTM.
May 7 2021
Is this really necessary? Our preference is to use custom combines/lowering passes, or custom legalization, to do this.
Address comments. Factor out tryEmitBZero into the utils file.
Remove CSE from the combiner, this saves an additional 10% of the runtime in the pass, with no effect on code size.
May 6 2021
Hadn't rerun test since an update. Move check to before the LI check so that it runs unconditionally.
May 5 2021
May 4 2021
Apr 30 2021
Apr 29 2021
Actually this seems to be already disabled on release builds, but my sampling was catching the empty set checks in analyzeDebugLocations(). Not a big enough deal to worry about.
Apr 28 2021
Wow, that was a nasty one. Thanks for tracking it down. LGTM.
Apr 26 2021
Remove constant folding check.
Apr 23 2021
Only run this for AArch64.
Apr 22 2021
- Add more tests.
- Factor out the APInt checking part of the constant folder to be used as a query.
- Enable CSEInfo in the postlegalizer combiner so that we don't have to instantiate a constant-folding MIRBuilder.