Merge 12 11 15 v2 #122
Merge 12 11 15 v2 #122
Conversation
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254827 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254828 91177308-0d34-0410-b5e6-96231b3b80d8
…simplicity git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254829 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254830 91177308-0d34-0410-b5e6-96231b3b80d8
…ts, and fix/remove the emission of a broken tu_index when no type units are present git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254833 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254837 91177308-0d34-0410-b5e6-96231b3b80d8
Different version of indexed format may use different name uniquing schemes for static functions. Pass the version info to the name interface so that different schmes can be picked (for profile lookup). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254838 91177308-0d34-0410-b5e6-96231b3b80d8
…tructions Both were defaulting to the float domain - now matches the packed instructions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254841 91177308-0d34-0410-b5e6-96231b3b80d8
…oded count and a multiply. The outputed code is identical. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254842 91177308-0d34-0410-b5e6-96231b3b80d8
…physical register arrays already use this typedef. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254843 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254844 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: If the same pass manager is used for multiple modules ASAN complains about GlobalsMD being initialized twice. Fix this by resetting GlobalsMD in a new doFinalization method to allow this use case. Reviewers: kcc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D14962 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254851 91177308-0d34-0410-b5e6-96231b3b80d8
…nt. getNumImplicitDefs contains a loop so its better to just loop over the null terminated implicit def list. NFC git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254852 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254854 91177308-0d34-0410-b5e6-96231b3b80d8
…g functions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254855 91177308-0d34-0410-b5e6-96231b3b80d8
…experiment with. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254856 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254857 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254859 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254860 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254861 91177308-0d34-0410-b5e6-96231b3b80d8
Note: missing 256-bit tests for min and max should also be added. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254862 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254863 91177308-0d34-0410-b5e6-96231b3b80d8
…t. NFC. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254864 91177308-0d34-0410-b5e6-96231b3b80d8
…stants. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254866 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254868 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: There are `SelectPatternFlavor`s that don't represent min or max idioms, and we should not be passing those to `getCmpPredicateForMinMax`. Fixes PR25745. Reviewers: majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15249 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254869 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254871 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254872 91177308-0d34-0410-b5e6-96231b3b80d8
Differential Revision: http://reviews.llvm.org/D15076 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254873 91177308-0d34-0410-b5e6-96231b3b80d8
This removes the code path that generate "synchronous" (only correct at call site) CFA. We will probably want to re-introduce it once we are capable of emitting different .eh_frame and .debug_frame sections. Differential Revision: http://reviews.llvm.org/D14948 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254874 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255322 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch, each function's on-disk VP data is 'pointed' to by the Value field of per-function ProfileData structue, and read relies on this field (relocated with ValueDataDelta field) to read the value data. However this means the Value field needs to be updated during runtime before dumping, which creates undesirable data races. With this patch, the reading of VP data no longer depends on Value field. There is no format change. ValueDataDelta header field becomes obsolute but will be kept for compatibility reason (will be removed next time the raw format change is needed). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255329 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255330 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255331 91177308-0d34-0410-b5e6-96231b3b80d8
|
LGTM |
|
@JosephTremoulet PTAL. CI will fail testing but I'll commit once I see clean builds. |
|
Looks like lots of test failures in the CI runs. While some failures (~30) are expected this seems to be way too many. I suspect something in the new LLVM bits has broken things. Will investigate. |
Conflicts: include/llvm/IR/CallingConv.h
AndyAyersMS
force-pushed
the
Merge-12-11-15-V2
branch
from
d19c259 to
587a26f
Compare
|
Merge was bad :-(. Resolved the conflict incorrectly. Updated. |
|
@dotnet-bot retest this please |
|
@JosephTremoulet chk has 14 failures, 11 timeouts. Looks like we're not quite ready to go yet. Sorry. |
|
Let me get the current LLILC clean and I'll see if I can get back to this tonight... but probably it will be tomorrow sometime. |
|
LLILC exclusions are now up to date. Going to see if I can repro some of those chk timeouts. |
|
Could not repro them, most of them pass quickly. The ones that caused validation errors (because of botched excludes) popped up dialogs, which explains there timeouts. I really need to stop the dialog popups (dotnet/llilc#582)... anyways this is puzzling but perhaps if one test does pop a dialog it messes up other tests too? Not sure.... Am going to kick off a retest with the latest LLILC excludes. |
|
@dotnet-bot retest this please |
|
Still not able to repro locally. Lab failures are very consistent. All the failing tests are interop-related. They all time out. So I suspect there's a dialog box sitting there on the lab machine. The lab is using VS2013 to build LLILC, while now I'm using VS2015, so will try a build with an older compiler to see if that shakes anything out. |
|
Actually it looks like the first two failures are the readytorun tests. Maybe they time out w/ a popup? |
|
Still trying to repro, no luck yet. |
It wants to assert that the subtarget is 64-bit, not the register. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255703 91177308-0d34-0410-b5e6-96231b3b80d8
|
Cherry-picked r255703 (aka 009fed3) to fix the assert we think is causing popups. This is not in our master branch yet, but should be there soon when the mirroring catches up. The assert was for an EFLAGS spill coming from gc transition end/pause lowering. We should fix thisgc not to spill the flags. Opened #124. |
|
@dotnet-bot retest this please (the run kicked off by the cherry-pick failed due to a network error) |
|
@JosephTremoulet I think we can probably merge this one, the CI failure is win32 release and appears to be infrastructure related.Agree? |
|
Also I wonder if the mirroring is broken, I thought it was supposed to trail the main LLVM git clone by 5 minutes or so? Last update was 21 hours ago. @adiaaida do you know? |
|
Interesting, dotnet-bot kicked off a re-run as requested, but the link here still points to the original run. The leg that failed in the original has already passed in the re-run, so yes I think we're good to merge. I'm not sure which step you mean by "the mirroring". I think that llvm.org exposes a git mirror of the svn repo. Regardless, I'm pretty sure that the llvm-mirror/llvm project on GitHub updates every five minutes from llvm.org. Our CI jobs pull from llvm-mirrof/llvm to Microsoft/llvm once per day. |
|
I should clarify -- pulling from llvm-mirror/llvm's master branch to Microsoft/llvm's master branch happens daily. (which is the same cadence as the automated attempted integrations from Microsoft/llvm's master branch to Microsoft/llvm's MS branch) |
|
Guess I confused the cadence of LLVM.org's SVN->llvm-mirror/llvm with llvm-mirror/llvm -> microsoft/llvm. Hopefully the cherry-pick doesn't cause trouble. I got the hash by fetching the commit history from llvm.org. Merging. |
No description provided.