- User Since
- Aug 17 2017, 6:34 AM (161 w, 2 d)
Thu, Sep 17
@ayermolo Hi Alexander, I rebased on latest but did not check whether current size/performance numbers match with reported previously.
Tue, Sep 15
Mon, Sep 14
Sun, Sep 6
retested(bootstrap with check-all),
added i386/i686 triples into X86/x32-va_start.ll,
regenerated tests with update_llc_test_checks.py.
Mon, Aug 31
@efriedma would you mind to take a look at this patch once more, please?
Thu, Aug 27
updated with recomendations from the thread.
Tue, Aug 25
The link to the llvm-dev with the proposal - http://lists.llvm.org/pipermail/llvm-dev/2020-August/144579.html
Aug 17 2020
Do we need better i686- triple testing?
Aug 16 2020
Do we need better i686- triple testing?
Aug 9 2020
Aug 6 2020
That is a fair argument for the "1" approach for .debug_ranges (although I doubt in practice it makes any difference). It doesn't really help .debug_loc though, since the behaviour there is currently broken in BFD land.
However, we can use ANY other single value (1, 2, 123456, -2 etc) except -1 which also has a special meaning, because semantically, those values all result in an empty range (-2, -2)/(1, 1) etc. There is no need for special handling within consumers for any given value in this case (or at least there shouldn't be), and thus the specific BFD-identical value for .debug_ranges shouldn't matter.
Aug 5 2020
Jul 12 2020
I'll wait and rebase after D82085.
Jul 11 2020
Jul 9 2020
Thank you, for the review.
Jul 8 2020
Jul 2 2020
@efriedma What do you think about current state of this patch? Is it OK?
Jun 28 2020
Jun 25 2020
removed early check for TRE candidates from canTRE().
Jun 24 2020
check valid TRE candidate into findTRECandidate()().
removed usages of AllocaDerivedValueTracker from canTRE().
Jun 23 2020
Jun 22 2020
Already integrated by this commit - https://reviews.llvm.org/rGa04ab2ec08014d36337d686d43ecef7668622f1b
- deleted code doing more strict tailcall marking.
- left removal of "AllCallsAreTailCalls".
- added check for non-capturing calls while tracking alloca.
- re-titled the patch.
Jun 19 2020
abandoned in favor D81784
Jun 18 2020
It makes sense to teach tail recursion elimination not to depend so heavily on tail markings. But I don't think that implies we want to mess with the markings themselves.
It's OK to set "tail" on any call that satisfies these requirements (from https://llvm.org/docs/LangRef.html#call-instruction): "Both markers [tail and musttail] imply that the callee does not access allocas from the caller. The tail marker additionally implies that the callee does not access varargs from the caller."
I am happy with it. There is a small comment inside. other than that lgtm.
Jun 15 2020
Jun 12 2020
(not used yaml, since there is a request to use asm.
added tests for various architectures, not added test for COMDAT
Jun 11 2020
would address all comments and rewrite test case with yaml.
Jun 10 2020
removed backward compatibility option.
Jun 9 2020
It looks like most common opinion is to not to create an option. Will remove it and update the patch.
Jun 8 2020
Case 2 should not occur, I think; the compiler should not produce a range where low/high point to different sections.
Yeah, I just worry then it becomes another source of inconsistency between consumers/producers/etc. Perhaps we could name it in some way that's clear that it might be removed later - to encourage people to either reach out to us to explain their use case, or to invest a bit more in working with the new default behavior.
I'd like to avoid adding a flag at all, if possible.
Do we have agreement on following option syntax;
Jun 1 2020
May 31 2020
rebased. updated according to the discussion on llvm-dev.
It is currently being discussed, so it could be changed more.
May 21 2020
May 20 2020
That patch was a prototype. Currently there is another implementation which uses code extracted from dsymutil - https://reviews.llvm.org/D74169. I abandone this patch in favor to https://reviews.llvm.org/D74169.
May 18 2020
May 15 2020
May 12 2020
Thank you! Would add comment before integrating.
May 11 2020
addressed comments(inlined register descriptor).
May 7 2020
Probably, it makes sense to not put printing code into DWARFLinker? i.e. add callbacks to DwarfFile:
May 6 2020
May 5 2020