User Details
- User Since
- Apr 23 2019, 12:56 PM (160 w, 5 d)
Mar 6 2022
Mar 4 2022
Feb 24 2022
Hi Louis,
Feb 23 2022
Feb 15 2022
Hi, I'm actually wondering how this is working for anyone.
Dec 6 2021
Updating diff to most recent: Want to see if CI actually starts working..
Nov 19 2021
Nov 17 2021
Apologies. I uploaded the full diff again, rather than the refinement I wanted to.
- Made ViewMISChedDAG a global option to match ForceTopDown et al.
- Optimized includes in VLIWMachineScheduler.h
- Replaced vectors in VLIWMachineScheduler.h with SmallVector
- Ran clang-format on all changes, which includes the entirety of the VLIWMachineScheduler files, as they are treated as 'new' files
Nov 9 2021
As-is, this patch will have the unintended effect that Clang and the
LLVM libraries (not only the runtime ones like libc++) will also be
built with -fPIC in the release.
Nov 4 2021
Nov 3 2021
Comments for review added.
This review is not yet formatted, but I'll upload a formatted version prior to commit once we find the changes sufficient. I wanted to avoid unrelated code changes from being injected into the review.
Sep 29 2021
You're welcome! Surprising that no downstream clang was running with the old PM and assertions...
Perhaps you could reproduce my error -round-trip-args on the -cc1 command line?
The trigger for the remark I'm seeing is llvm::shouldInline in InlineAdvisor.cpp ((https://github.com/llvm/llvm-project/blob/2240deb9766cc080b351016b0d7f975d7249b113/llvm/lib/Transforms/IPO/Inliner.cpp#L425) which is called in a top-level AlwaysInlinerLegacyPass
I'll take a quick look tomorrow, but the general idea is that on calling ParseOptimizationRemark on line 1909 with a -cc1 command line containing -Rpass=inline -Rno-pass, Opts.OptimizationRemarkMissed and Opts.OptimizationRemarkAnalysis are set to valid patterns (Regex is ".*", Pattern is "", and Kind is RK_Missing). This happens around line 1909 in the change set.
Sep 28 2021
Have they added a way to do that? I recall there being some discussions, but as far as I know, I'd have to XFAIL the whole test, not just specific lines.
Either way, this isn't a blocking issue on our end. I just wanted to bring it up in case someone else has the same problem and can see from where it originates.
Sep 27 2021
Pass manager problems? That crossed my mind because we have been slow on the uptake of the new PM, but seeing the behavior in the clang function made me believe that it couldn't have been the case. Wouldn't just making -Rpass not turn on pass-misses and pass-analysis solve the issue?
In this commit, our team is seeing a failure in the optimization_remark.c test you modified, but not on a line you changed. The failure occurs on line 16, and I'm trying to understand why other upstream targets aren't seeing the same.
The relevant command line options are:
Sep 22 2021
Adding relevant people from my team.
Aug 10 2021
Jul 30 2021
Hi all,
Jul 2 2021
Jul 1 2021
Mar 11 2021
I want to apologize for missing such obvious things. Perhaps I used all of my observational power on my initial investigation. Of course it checks the triple for *hf and then the leading arch for arm, since that's how the property is added to the triple (*-eabihf)
Oh! Sorry, I glazed over that block and missed the set. I suspect that an architecture called '^arm.*hf$' doesn't cause issues in builtins specifically because it seems there's no special casing for anything besides 'armhf'
Mar 10 2021
This commit has broken our downstream toolchain builds which utilizes the llvm runtimes system to compile multiple sets of libraries with a just-built cross compiler.
Oct 14 2020
I believe our teams' downstream Darwin (cross compiler to ARM) builds are failing due to this commit:
Oct 6 2020
In llvm/test/DebugInfo/dwarfdump-debug-frame-simple.test
Aug 28 2020
Aug 21 2020
Aug 18 2020
This commit is causing build failures in my downstream ARM repository, as well as at least one buildbot (http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux)
Aug 4 2020
Abandoning in lieu of fix in D85215
Moved test to X86 subdirectory
Either of these options sounds good to me.
Aug 3 2020
I apologize for the constant early changes. I forget how phabricator catches and marks things as being referenced, so I was trying to get it to work.
This is a patch fix for D69384, which has broken ARM build bots. I present this as a band-aid since this feature and its test seems to be rather generic.
May 20 2020
May 15 2020
The problem here is the method we reset the variables in the cache back to their cached value.
May 13 2020
Actually, it's very fortuitous that you reminded of this review today.
When @phosek gets back to it, one of you would need to commit it on my behalf.
Apr 16 2020
Unfortunately I don't have commit access.
Could one of you get this onto the upstream?
Apr 15 2020
This commit broke our validations. Specifically, the tests in llvm/test/tools/opt-viewer
Mar 27 2020
@bkramer committed a fix for a crash in LegalizeFloatTypes where this operator appeared in SoftPromoteHalfResult
Jan 31 2020
Thanks @phosek
Jan 30 2020
Jan 27 2020
Jan 23 2020
Moved option into a block guarded by COMPILER_RT_STANDLONE_BUILD, to indicate that it is an option that is available when not utilizing a linked LLVM toolchain and its configuration.
Jan 20 2020
Jan 17 2020
Updated to reflect master -> diff 2, rather than diff 1 -> diff 2
Confirmed that cmake correctly identifies '.S' as ASM, and uses CMAKE_ASM_FLAGS
Jan 13 2020
@phosek or really any other committer, could we get this onto master?
Dec 22 2019
Sadly, I do not have commit access. Could you do the honors @phosek ?
Dec 20 2019
This foreach loop goes over each variable, yes?
If so, then I'm not sure this change does what is required.
Dec 16 2019
Nov 18 2019
This commit has broken a few build bots.
Oct 11 2019
Sadly I'm home from the weekend, so I can't post more diffs for the renaming.
Here's a link to a github search though! I think this would be all the places: https://github.com/llvm/llvm-project/search?q=iterface&unscoped_q=iterface
Our team maintains a downstream embedded ARM clang distribution and some tests from this commit have begun to fail for us.
For a number of these tests, there was a REQUIRES: x86-registered-target at the top, which has now been removed. Specifically, externstatic.c, merge-conflict-test.c, object-float.c, and object.c are failing.
Sep 13 2019
Ah! My apologies. I had not pulled anything new down, as our process tends to hard-stop until an issue is resolved (something I'm thinking needs to be a little more flexible).
As mentioned in an inline comment, the test only works if the sizeof(int) != sizeof(int *) and sizeof(unsigned long long) == sizeof(int)