Page MenuHomePhabricator
Feed Advanced Search

Mar 8 2019

mgrang updated the diff for D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.
Mar 8 2019, 12:14 PM · Restricted Project, Restricted Project

Mar 6 2019

mgrang added inline comments to D39050: Add index-while-building support to Clang.
Mar 6 2019, 10:18 AM

Mar 4 2019

mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

@NoQ Ping 2 for reviews please.

Mar 4 2019, 3:42 PM · Restricted Project, Restricted Project

Mar 1 2019

mgrang committed rGa14f20c5b3be: [ProfileData] Sort FuncData before iteration to remove non-determinism (authored by mgrang).
[ProfileData] Sort FuncData before iteration to remove non-determinism
Mar 1 2019, 4:49 PM
mgrang committed rL355252: [ProfileData] Sort FuncData before iteration to remove non-determinism.
[ProfileData] Sort FuncData before iteration to remove non-determinism
Mar 1 2019, 4:47 PM
mgrang closed D57986: [ProfileData] Sort FuncData before iteration to remove non-determinism.
Mar 1 2019, 4:47 PM · Restricted Project, Restricted Project
mgrang updated the diff for D57986: [ProfileData] Sort FuncData before iteration to remove non-determinism.

Addressed comments.

Mar 1 2019, 4:29 PM · Restricted Project, Restricted Project
mgrang committed rGba4538708a52: [llvm] Fix typo: 's/analsyis/analysis/' [NFC] (authored by mgrang).
[llvm] Fix typo: 's/analsyis/analysis/' [NFC]
Mar 1 2019, 4:16 PM
mgrang committed rL355246: [llvm] Fix typo: 's/analsyis/analysis/' [NFC].
[llvm] Fix typo: 's/analsyis/analysis/' [NFC]
Mar 1 2019, 4:16 PM
mgrang edited reviewers for D58835: [Support] Treat truncation of fullpath as error, added: efriedma; removed: eli.friedman.
Mar 1 2019, 11:46 AM · Restricted Project
mgrang updated the diff for D57986: [ProfileData] Sort FuncData before iteration to remove non-determinism.
Mar 1 2019, 11:35 AM · Restricted Project, Restricted Project
mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

But, as a work-in-progress alpha checker, the direction is set and looks great. Please let @NoQ have the final say.

Thanks a lot @Szelethus! I will wait for @NoQ 's comments.

Mar 1 2019, 11:12 AM · Restricted Project, Restricted Project

Feb 28 2019

mgrang updated the diff for D57986: [ProfileData] Sort FuncData before iteration to remove non-determinism.
Feb 28 2019, 8:39 PM · Restricted Project, Restricted Project
mgrang added a comment to D58787: [ProfileData] Sort ProfilingData by hash.

How about we keep the discussion on the original patch (D57986)? I think we explored the problem space a fair bit there & I'll advocate for the same thing here as I did there: Sorting before emission is likely more efficient than keeping a continuously sorted container, if there's a separate "build" and "iterate" phase you can sort between. At least that's my understanding. std::map and MapVector would both grow memory usage, probably not prohibitively, but a fair bit.

Especially if these are just small clusters of collisions - they can be put in a small container, sorted, emitted, then thrown away - better than changing the whole long-lived/larger data structure.

Feb 28 2019, 5:40 PM · Restricted Project
mgrang updated the diff for D57986: [ProfileData] Sort FuncData before iteration to remove non-determinism.
Feb 28 2019, 5:38 PM · Restricted Project, Restricted Project
mgrang added inline comments to D58787: [ProfileData] Sort ProfilingData by hash.
Feb 28 2019, 10:38 AM · Restricted Project
mgrang added a comment to D58787: [ProfileData] Sort ProfilingData by hash.

Sorry, I just saw this now. I had a patch to fix this issue (but I didn't get time to follow-up on it). See D57986.

Feb 28 2019, 10:35 AM · Restricted Project

Feb 26 2019

mgrang added inline comments to D53379: GSYM symbolication format.
Feb 26 2019, 9:51 AM

Feb 25 2019

mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

But, as a work-in-progress alpha checker, the direction is set and looks great. Please let @NoQ have the final say.

Feb 25 2019, 12:10 PM · Restricted Project, Restricted Project
mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

So I was able compile a couple of C++ code bases through csa-testbench. I built cppcheck and tinyxml2 without any problems. cppcheck has one invocation std::sort but the keys are not pointers whereas tinyxml2 does not use std::sort. I tried bitcoin, rtags, xerces but run into a lot of configure/build errors.

Thats great. How about LLVM+Clang? That'll be a pain in the butt to analyze, but is pretty great for testing. Also, did you clone rtags with the git option --recursive?

Feb 25 2019, 12:09 PM · Restricted Project, Restricted Project
mgrang added inline comments to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.
Feb 25 2019, 12:02 PM · Restricted Project, Restricted Project
mgrang updated the diff for D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.
Feb 25 2019, 11:57 AM · Restricted Project, Restricted Project

Feb 22 2019

mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

bitcoin:

sudo apt-get install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils python3 libboost-all-dev software-properties-common libminiupnpc-dev libzmq3-dev libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler
sudo add-apt-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install libdb4.8-dev libdb4.8++-dev

git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin

./autogen.sh
./configure
CodeChecker log -b "make -j13" -o compile_commands.json

xerces:

wget http://www-eu.apache.org/dist//xerces/c/3/sources/xerces-c-3.2.2.tar.gz
tar xf xerces-c-3.2.2.tar.gz
mv xerces-c-3.2.2 xerces
rm xerces-c-3.2.2.tar.gz
cd xerces

./configure
CodeChecker log -b "make -j13" -o compile_commands.json

where -j13 means 13 threads.

Feb 22 2019, 4:51 PM · Restricted Project, Restricted Project
mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

So I was able compile a couple of C++ code bases through csa-testbench. I built cppcheck and tinyxml2 without any problems. cppcheck has one invocation std::sort but the keys are not pointers whereas tinyxml2 does not use std::sort. I tried bitcoin, rtags, xerces but run into a lot of configure/build errors.

Feb 22 2019, 10:42 AM · Restricted Project, Restricted Project

Feb 21 2019

mgrang committed rG096fae32b369: [llvm] Fix typo: 's/ ot / to /' [NFC] (authored by mgrang).
[llvm] Fix typo: 's/ ot / to /' [NFC]
Feb 21 2019, 12:04 PM
mgrang committed rL354614: [llvm] Fix typo: 's/ ot / to /' [NFC].
[llvm] Fix typo: 's/ ot / to /' [NFC]
Feb 21 2019, 12:04 PM
mgrang committed rG3b75622fd2e7: [test] Fix typo: 's/ ot / to /' [NFC] (authored by mgrang).
[test] Fix typo: 's/ ot / to /' [NFC]
Feb 21 2019, 11:11 AM
mgrang committed rL354608: [test] Fix typo: 's/ ot / to /' [NFC].
[test] Fix typo: 's/ ot / to /' [NFC]
Feb 21 2019, 11:11 AM
mgrang committed rC354608: [test] Fix typo: 's/ ot / to /' [NFC].
[test] Fix typo: 's/ ot / to /' [NFC]
Feb 21 2019, 11:11 AM

Feb 20 2019

mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

So I was able compile a couple of C++ code bases through csa-testbench. I built cppcheck and tinyxml2 without any problems. cppcheck has one invocation std::sort but the keys are not pointers whereas tinyxml2 does not use std::sort. I tried bitcoin, rtags, xerces but run into a lot of configure/build errors.

Feb 20 2019, 5:29 PM · Restricted Project, Restricted Project
mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

It's because it invokes CodeChecker, which by default enables valist.Uninitialized, but not ValistBase. Do you have assert failures after my hotfix?

@Szelethus Thanks. I run into this assert when run through CodeChecker:

Assertion `CheckerTags.count(tag) != 0 && "Requested checker is not registered! Maybe you should add it as a " "dependency in Checkers.td?"'

Is there a workaround?

Uhh, I'm afraid the only way out is to actually fix the problem :) couple questions:

  1. Are you *sure* that you rebased to rC354235 (which is the hotfix I mentioned), CodeChecker runs *that* clang when the assert failure happens?
Feb 20 2019, 4:53 PM · Restricted Project, Restricted Project
mgrang updated the diff for D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.
Feb 20 2019, 4:41 PM · Restricted Project, Restricted Project

Feb 19 2019

mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

There is a revision to solve this problem here: D58065. I guess your input, as someone who didn't participate in the checker dependency related patch reviews would be invaluable, in terms of whether my description is understandable enough.

Feb 19 2019, 4:27 PM · Restricted Project, Restricted Project
mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

Also I don't see the helptext for PointerSorting when I run:

Feb 19 2019, 4:23 PM · Restricted Project, Restricted Project
mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

It's because it invokes CodeChecker, which by default enables valist.Uninitialized, but not ValistBase. Do you have assert failures after my hotfix?

Feb 19 2019, 4:23 PM · Restricted Project, Restricted Project
mgrang updated the diff for D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.
Feb 19 2019, 4:20 PM · Restricted Project, Restricted Project
mgrang added inline comments to D58065: [analyzer] Document the frontend library.
Feb 19 2019, 4:15 PM · Restricted Project
mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

Yeah, it seems upstream has moved away due to @Szelethus' implementation of a much more manageable "checker dependency" system. You most likely will have to rebase your patch first, then check what you missed which got added to other merged, existing checkers.

Feb 19 2019, 11:23 AM · Restricted Project, Restricted Project
mgrang updated the diff for D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.
Feb 19 2019, 11:18 AM · Restricted Project, Restricted Project

Feb 15 2019

mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

I hacked around the run_experiments.py to set CMAKE_C_FLAGS and now I see the following error in stats.html. Note: I see the same error with an existing checker like PointerArithmChecker. And I do not hit this assert when I run the checker outside of csa-testbench.

Feb 15 2019, 3:58 PM · Restricted Project, Restricted Project
mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

The error I now get is:

clang is not able to compile a simple test program.
/usr/bin/ld: unrecognised emulation mode: armelf_linux_eabi
  Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu i386linux
  elf_l1om elf_k1om i386pep i386pe
Feb 15 2019, 12:56 PM · Restricted Project, Restricted Project

Feb 14 2019

mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

I guess I hadn't sourced the CodeChecker venv correctly. Now that I did source it and started the CodeChecker server I seem to be progressing. The error I get now is compiler related (which I will dig into).

Feb 14 2019, 12:56 PM · Restricted Project, Restricted Project
mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

Reviving this now that I have some cycles to work on this.

So I tried running this on csa-testbench projects but I didn't have much success. I always run into a bunch of build/env related errors:

python run_experiments.py --config myconfig.json

15:05:20 [libcxx] Checking out project... 
[ERROR] Unknown option: json

15:05:22 [libcxx] LOC: ?.
15:05:22 [libcxx] Generating build log... 
15:05:22 [libcxx_master] Analyzing project... 
[ERROR] Traceback (most recent call last):
  File "/local/mnt/workspace/mgrang/comm_analyzer/CodeChecker/cc_bin/CodeChecker.py", line 20, in <module>
    from shared.ttypes import RequestFailed
ImportError: No module named shared.ttypes

Hi!

Sorry for the late response. Does CodeChecker work for you (when not using the testbench)?
I think one of the most common reason for such errors is when we do not source the virtualenv of CodeChecker so the dependencies are not available.

Feb 14 2019, 12:47 PM · Restricted Project, Restricted Project
mgrang added a comment to D57986: [ProfileData] Sort FuncData before iteration to remove non-determinism.

Ping for reviews please.

Feb 14 2019, 9:18 AM · Restricted Project, Restricted Project

Feb 12 2019

mgrang added a comment to D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.

Reviving this now that I have some cycles to work on this.

Feb 12 2019, 3:06 PM · Restricted Project, Restricted Project
mgrang updated the diff for D50488: [Analyzer] Checker for non-determinism caused by sorting of pointer-like elements.
Feb 12 2019, 3:01 PM · Restricted Project, Restricted Project

Feb 10 2019

mgrang committed rGea246114bbed: [GlobalISel] Regex the opcodes in unit test to fix non-deterministic ordering (authored by mgrang).
[GlobalISel] Regex the opcodes in unit test to fix non-deterministic ordering
Feb 10 2019, 11:56 AM
mgrang committed rL353652: [GlobalISel] Regex the opcodes in unit test to fix non-deterministic ordering.
[GlobalISel] Regex the opcodes in unit test to fix non-deterministic ordering
Feb 10 2019, 11:56 AM
mgrang closed D57988: [GlobalISel] Regex the opcodes in unit test to fix non-deterministic ordering.

Committed in r353652.

Feb 10 2019, 11:56 AM · Restricted Project

Feb 8 2019

mgrang added a comment to D57988: [GlobalISel] Regex the opcodes in unit test to fix non-deterministic ordering.

legalize-ext-csedebug-output.mir fails in a reverse iteration build because the OpcodeHitTable is a DenseMap and is iterated to print CSEInfo. We could have copied OpcodeHitTable to a vector and sorted it before iteration. Maybe that would be an overkill. I saw this comment in the test that we could regex the opcodes. Do we care about the order of the CSEInfo opcodes?

Feb 8 2019, 5:07 PM · Restricted Project
mgrang created D57988: [GlobalISel] Regex the opcodes in unit test to fix non-deterministic ordering.
Feb 8 2019, 5:02 PM · Restricted Project
mgrang added a comment to D57986: [ProfileData] Sort FuncData before iteration to remove non-determinism.

tools/llvm-profdata/instr-remap.test is failing in the reverse iteration bot. See http://lab.llvm.org:8011/builders/reverse-iteration/builds/10546/steps/check_all/logs/stdio.

Feb 8 2019, 4:36 PM · Restricted Project, Restricted Project
mgrang created D57986: [ProfileData] Sort FuncData before iteration to remove non-determinism.
Feb 8 2019, 4:32 PM · Restricted Project, Restricted Project

Feb 1 2019

mgrang committed rL352945: [AutoUpgrade] Fix AutoUpgrade for x86.seh.recoverfp.
[AutoUpgrade] Fix AutoUpgrade for x86.seh.recoverfp
Feb 1 2019, 5:32 PM
mgrang closed D57614: [AutoUpgrade] Fix AutoUpgrade for x86.seh.recoverfp.
Feb 1 2019, 5:32 PM · Restricted Project
mgrang committed rL352940: [AArch64] Fix unused variable [NFC].
[AArch64] Fix unused variable [NFC]
Feb 1 2019, 3:42 PM
mgrang added a comment to D57183: [COFF, ARM64] Fix localaddress to handle stack realignment and variable size objects.

Great to have this. Thanks @mgrang. Curious on what remaining tests fail in xcpt4u.c?

Feb 1 2019, 1:43 PM · Restricted Project
mgrang committed rL352923: [COFF, ARM64] Fix localaddress to handle stack realignment and variable size….
[COFF, ARM64] Fix localaddress to handle stack realignment and variable size…
Feb 1 2019, 1:41 PM
mgrang closed D57183: [COFF, ARM64] Fix localaddress to handle stack realignment and variable size objects.
Feb 1 2019, 1:41 PM · Restricted Project
mgrang updated the diff for D57614: [AutoUpgrade] Fix AutoUpgrade for x86.seh.recoverfp.

Added unit test.

Feb 1 2019, 1:32 PM · Restricted Project
mgrang updated the diff for D57183: [COFF, ARM64] Fix localaddress to handle stack realignment and variable size objects.
Feb 1 2019, 12:39 PM · Restricted Project
Herald added a project to D56747: [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp: Restricted Project.
Feb 1 2019, 12:38 PM · Restricted Project
mgrang created D57614: [AutoUpgrade] Fix AutoUpgrade for x86.seh.recoverfp.
Feb 1 2019, 12:38 PM · Restricted Project

Jan 30 2019

mgrang added a reviewer for D57183: [COFF, ARM64] Fix localaddress to handle stack realignment and variable size objects: TomTan.
Jan 30 2019, 4:51 PM · Restricted Project
mgrang added a comment to D57183: [COFF, ARM64] Fix localaddress to handle stack realignment and variable size objects.

With this patch, most of the SEH tests in https://github.com/Microsoft/windows_seh_tests/blob/master/src/xcpt4/xcpt4u.c pass.

Jan 30 2019, 4:47 PM · Restricted Project
mgrang retitled D57183: [COFF, ARM64] Fix localaddress to handle stack realignment and variable size objects from [COFF, ARM64] Fix localaddress to handle stack realignment to [COFF, ARM64] Fix localaddress to handle stack realignment and variable size objects.
Jan 30 2019, 4:34 PM · Restricted Project
mgrang added a comment to D57183: [COFF, ARM64] Fix localaddress to handle stack realignment and variable size objects.

Deleted test/CodeGen/AArch64/seh-localescape.ll as localescape testing is better covered under the updated test/CodeGen/AArch64/seh-finally.ll.

Jan 30 2019, 4:32 PM · Restricted Project
mgrang updated the diff for D57183: [COFF, ARM64] Fix localaddress to handle stack realignment and variable size objects.
Jan 30 2019, 4:31 PM · Restricted Project

Jan 25 2019

mgrang added a comment to D57183: [COFF, ARM64] Fix localaddress to handle stack realignment and variable size objects.

In the existing code, there are several conditions on when FP/BP/SP should be used. I have tried to summarize them here:

Jan 25 2019, 2:19 PM · Restricted Project

Jan 24 2019

mgrang added a comment to D57183: [COFF, ARM64] Fix localaddress to handle stack realignment and variable size objects.

If there's a call to localaddress in a function without funclets or VLAs, we should use sp, yes. That should be rare in practice, but I guess the testcase is an example.

Jan 24 2019, 4:18 PM · Restricted Project
mgrang created D57183: [COFF, ARM64] Fix localaddress to handle stack realignment and variable size objects.
Jan 24 2019, 1:22 PM · Restricted Project
mgrang abandoned D57115: [llvm] Remove dependency on <algorithm> [NFC].

I wanted to clean up the inclusions of algorithm due to std::sort. But seems like this change may potentially break some things. So for now we can let it pass? (Meaning I can abandon this patch).

Yep - thanks for trying, but unless you can get something like IWYU working to help ensure this cleanup is a bit more robust - I'd probably suggest just abandoning this change, unfortunately.

Jan 24 2019, 11:19 AM
mgrang added a comment to D57115: [llvm] Remove dependency on <algorithm> [NFC].

I wanted to clean up the inclusions of algorithm due to std::sort. But seems like this change may potentially break some things. So for now we can let it pass? (Meaning I can abandon this patch).

Jan 24 2019, 11:03 AM
mgrang added a comment to D57115: [llvm] Remove dependency on <algorithm> [NFC].

@mgrang Which compilers/oses have you tested in your ninja build? asserts? EXPENSIVE_CHECKS?

Jan 24 2019, 11:02 AM

Jan 23 2019

mgrang added a comment to D57115: [llvm] Remove dependency on <algorithm> [NFC].

"mainly" used for std::sort might be true, but "only" used might be harder to prove - did you use any tooling to test that these inclusions weren't needed other than "this code still compiles" (which has the problem that the inclusion might be used, but also included indirectly from some other header - so removing it may still compile, but introduces an undesirable indirect dependency on an implementation detail of some other header)

I ran ninja check-all and did not see any failures. I haven't changed the places where algorithm is needed (like for std::fill, etc) and which introduced compile errors. I have also not touched examples, unittests and util/unittest directories.

How did you identify these "I haven't changed the places where algorithm is needed (like for std::fill, etc)" places? By visual inspection of every file that's been touched?

Jan 23 2019, 12:55 PM
mgrang added a comment to D57115: [llvm] Remove dependency on <algorithm> [NFC].

"mainly" used for std::sort might be true, but "only" used might be harder to prove - did you use any tooling to test that these inclusions weren't needed other than "this code still compiles" (which has the problem that the inclusion might be used, but also included indirectly from some other header - so removing it may still compile, but introduces an undesirable indirect dependency on an implementation detail of some other header)

Jan 23 2019, 12:45 PM
mgrang created D57115: [llvm] Remove dependency on <algorithm> [NFC].
Jan 23 2019, 12:39 PM

Jan 18 2019

mgrang committed rLLD351612: [lld] Use range-based llvm::sort.
[lld] Use range-based llvm::sort
Jan 18 2019, 3:45 PM
mgrang committed rL351612: [lld] Use range-based llvm::sort.
[lld] Use range-based llvm::sort
Jan 18 2019, 3:45 PM
mgrang committed rL351574: [GlobalISel] Change to range-based invocation of llvm::sort.
[GlobalISel] Change to range-based invocation of llvm::sort
Jan 18 2019, 10:58 AM
mgrang committed rC351573: [clang] Change to range-based invocation of llvm::sort.
[clang] Change to range-based invocation of llvm::sort
Jan 18 2019, 10:49 AM
mgrang committed rL351573: [clang] Change to range-based invocation of llvm::sort.
[clang] Change to range-based invocation of llvm::sort
Jan 18 2019, 10:49 AM

Jan 17 2019

mgrang committed rL351502: [polly] Change to range-based invocation of llvm::sort.
[polly] Change to range-based invocation of llvm::sort
Jan 17 2019, 5:10 PM

Jan 16 2019

mgrang committed rL351370: [COFF, ARM64] Implement support for SEH extensions __try/__except/__finally.
[COFF, ARM64] Implement support for SEH extensions __try/__except/__finally
Jan 16 2019, 11:57 AM
mgrang closed D53540: [COFF, ARM64] Implement support for SEH extensions __try/__except/__finally.
Jan 16 2019, 11:57 AM
mgrang abandoned D53541: [COFF, ARM64] Do not emit x86_seh_recoverfp intrinsic.

I have added a default lowering for llvm.eh.recoverfp in D53540. So this patch is no longer needed.

Jan 16 2019, 11:46 AM
mgrang added a comment to D53540: [COFF, ARM64] Implement support for SEH extensions __try/__except/__finally.

@rnk @efriedma Thanks a lot for all your valuable review comments. I'll commit this now :)

Jan 16 2019, 11:41 AM
mgrang updated the diff for D53540: [COFF, ARM64] Implement support for SEH extensions __try/__except/__finally.
Jan 16 2019, 11:38 AM

Jan 15 2019

mgrang updated the diff for D53540: [COFF, ARM64] Implement support for SEH extensions __try/__except/__finally.

Added a default lowering for llvm.eh.recoverfp intrinsic.

Jan 15 2019, 5:20 PM
mgrang added inline comments to D56747: [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp.
Jan 15 2019, 5:15 PM · Restricted Project
mgrang committed rL351281: [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp.
[EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp
Jan 15 2019, 4:41 PM
mgrang closed D56747: [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp.
Jan 15 2019, 4:41 PM · Restricted Project
mgrang updated the diff for D56747: [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp.
Jan 15 2019, 4:33 PM · Restricted Project
mgrang updated the diff for D56747: [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp.

Rebased.

Jan 15 2019, 4:08 PM · Restricted Project
mgrang updated the diff for D56747: [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp.
Jan 15 2019, 3:41 PM · Restricted Project
mgrang added a comment to D53541: [COFF, ARM64] Do not emit x86_seh_recoverfp intrinsic.

I have renamed llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp in D56747 and D56748.

Jan 15 2019, 3:21 PM
mgrang updated the summary of D56747: [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp.
Jan 15 2019, 3:21 PM · Restricted Project
mgrang created D56748: [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp.
Jan 15 2019, 3:20 PM
mgrang created D56747: [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp.
Jan 15 2019, 3:19 PM · Restricted Project
mgrang added a comment to D53541: [COFF, ARM64] Do not emit x86_seh_recoverfp intrinsic.
In D53541#1358210, @rnk wrote:

I can't compile the example you gave yet because I haven't applied your patches locally, but this is the "three stack pointer" case that I have in mind:

struct Foo {
  void (*ptr)();
  int x, y, z;
};

void escape(void *);
void large_align(int a0, int a1, int a2, int a3, int a4, int a5, int a6, int a7,
                 int stackarg) {
  struct Foo __declspec(align(32)) alignedlocal;
  alignedlocal.x = 42;
  int vla[a0];
  escape(&alignedlocal);
  vla[0] = stackarg;
  escape(&vla[0]);
}

This is LLVM's generated code:

"?large_align@@YAXHHHHHHHHH@Z":         ; @"?large_align@@YAXHHHHHHHHH@Z"
.seh_proc "?large_align@@YAXHHHHHHHHH@Z"
; %bb.0:                                ; %entry
        stp     x21, x22, [sp, #-48]!   ; 16-byte Folded Spill
        stp     x19, x20, [sp, #16]     ; 16-byte Folded Spill
        stp     x29, x30, [sp, #32]     ; 16-byte Folded Spill
        add     x29, sp, #32            ; =32
        sub     x9, sp, #48             ; =48
        and     sp, x9, #0xffffffffffffffe0
        mov     x19, sp
        mov     w8, #42
        str     w8, [x19, #8]
        mov     w8, w0
        ldr     w22, [x29, #16]
        lsl     x8, x8, #2
        add     x8, x8, #15             ; =15
        lsr     x15, x8, #4
        mov     x21, sp
        bl      __chkstk
        mov     x8, sp
        sub     x20, x8, x15, lsl #4
        mov     sp, x20
        add     x0, x19, #0             ; =0
        bl      "?escape@@YAXPEAX@Z"
        mov     x0, x20
        str     w22, [x20]
        bl      "?escape@@YAXPEAX@Z"
        mov     sp, x21
        sub     sp, x29, #32            ; =32
        ldp     x29, x30, [sp, #32]     ; 16-byte Folded Reload
        ldp     x19, x20, [sp, #16]     ; 16-byte Folded Reload
        ldp     x21, x22, [sp], #48     ; 16-byte Folded Reload
        ret

I see three pointers used to address the stack:

  • sp: to address vla
  • x19: to address locals, the so-called "base" pointer
  • x29: to address parameters on the stack, looks like the traditional FP, points to FP+LR pair as well

At least for x86, the unwind info doesn't describe X19, it just describes X29, since that's what you need to restore CSRs and find the parent stack frame. We saw that the Windows EH runtime passes in some value based on the unwind info. For x86, it was just whatever EBP held, so recoverfp simply aligns that value forward to recover the base pointer (ESI) and then uses that to recover locals. For x64, the runtime passes in the value of RSP after the prologue ends, so we adjust it by the "parent frame offset" to get back the value we put in RBP. It looks like for x64 we never handled the case I'm asking you about, because this program doesn't print the right value:

#include <stdio.h>
struct Foo {
  void (*ptr)();
  int x, y, z;
};
int filter(int n) {
  printf("o.x: %d\n", n);
  return 1;
}
void may_throw() {
  __builtin_trap();
}
int main() {
  struct Foo __declspec(align(32)) o;
  o.x = 42;
  __try {
    may_throw();
  } __except(filter(o.x)) {
  }
}

I get "o.x: 0" instead of 42. I bet we can find something about that in bugzilla somewhere. =/

So, hopefully that explains the intended purpose of llvm.x86.seh.recoverfp, and why we might need to generalize it into something non-x86 specific. Maybe llvm.eh.recoverfp. Let me know if I can clarify anything else.

Jan 15 2019, 11:40 AM