The new API doesn't let you eliminate *all* checks. :-)
Also it introduces some new dependencies as noted inline.
The new API doesn't let you eliminate *all* checks. :-)
Fri, Jun 21
Pick whatever mechanism you like, we should debate it in that patch not here. :-)
Ah, hadn't considered statefulness. But if you layer another class on top of DataExtractor to handle the error flag, it would have to be replicating all the offset-is-valid checks, because of course DataExtractor itself doesn't return errors.
Removing that llvm_unreachable is fine, in that case.
The idea for error handling for DataExtractor sounds reasonable, looks like adding an error flag wouldn't even increase the size.
Thu, Jun 20
LGTM but give the West Coast folks a chance to look at it.
I think I am happy with this, leaving the rest up to James.
Looks pretty good, and thanks especially for the error-case tests!
I'll give other folks a chance to chime in if they want to.
Wed, Jun 19
We do not precisely match gcc/gas behavior in some more-peculiar cases, but my assertion is that those should not occur "naturally" and so it's okay. For example:
foo: nop .file 1 "a.c"
This will cause gcc/gas to emit an error to the effect that file number 1 is already defined (implicitly, because of the line-table record for the first instruction). Clang/llvm-mc will not, we'll just emit an odd-looking line table. I can see how to cause clang/llvm-mc to emit this error, but it feels like it would be a hack done just to match gcc's (likely unintentional) error-detection behavior for an ill-formed assembler file.
In any event, this is a project policy change and should have an RFC on llvm-dev, not be proposed in a patch.
Tue, Jun 18
I think this is a definite improvement in readability, once you fix the two places that seem to have lost a line of commentary.
I see the point; certainly when someone emails a patch, the first response is almost always "can you put this on Phab."
The dwarfdump changes look okay, but the new tests don't exercise those changes. The simplest thing is probably to RUN llvm-dwarfdump in relax-debug-frame.ll and verify the output describes the frame as expected.
Requiring Phabricator raises the barrier to one-off patches from casual contributors, because using Phabricator requires a registration step.
I don't think we should require it until casual users with drive-by patches can contribute easily.
Mon, Jun 17
Regarding what to call the @LINE+offset form, I think it's fine to call it "legacy" in the user-facing documentation, but it gets to be a bit much in the internals. I haven't commented every use but you will get the idea in the inline comments.
As I mentioned in PR38449, I plan to look at this starting this week. Even benign situations such as
foo: .file 1 "a.c"
are tripping over the assertion. I think the correct tactic is not to remove the places that are doing the checks, but make those places do a better job of tidying up anything that had been done in response to the command-line -g in favor of allowing the embedded directives to DTRT.
Wed, Jun 5
I am pretty sure all @jhenderson comments have been addressed, and I'm happy, so LGTM.
As I said previously, it may be a while before I get to your next patch.
Tue, Jun 4
Ah ha. The ParenGroup referring to the CHECK line as it has been translated for consumption by the underlying regex package... that was not clear.
In which case the terminology is okay but the commentary could be better, see inline comment.
Grammar nits and one longer point, which is:
I understand where the "parenthesis group" term came from, but I think it's not appropriate here. While a CHECK line is implicitly a regex, and variables are a kind of back-reference, the syntax for variable references (use or def) is not parentheses and the content is not a "group" in any real sense, and so "parenthesis group" is an un-obvious and confusing term.
Because FileCheck uses square brackets, I propose that the least disruptive change at this point would be to call them "bracket expressions." The "bracket" part is obvious, and "expression" because (a) definitions will have a regex, and (b) numeric variable references are implicitly expressions. (Okay, still a bit of a stretch, but less so that "parenthesis group" IMO.)
Is the compiler missing a check that these parameters are immediates?
Mon, Jun 3
This is intentional behavior in clang (controllable under the -f[no-]split-dwarf-inlining flag, and modified by the -f[no-]debug-info-for-profiling flag).
This extra debug info is used for online symbolication (in the absence of .dwo files) - such as for the sanitizers (accurate symbolication is necessary for correctness in msan, due to msan's necessary use of blacklisting to avoid certain false positives) and some forms of sample based profiling collection.
In the default mode, clang includes, as you noted, just the subprograms that have inlined subroutines in them in this split-dwarf-inlining data.
In -fdebug-info-for-profiling all subprograms are described in the skeleton CU with some minimal attributes (they don't need parameters, local variables/scopes, etc) necessary to do certain profile things I don't know lots about.
Well, the results are at least defined now. Please make sure the commit log mentions "e.g. fold-sext-trunc.ll".
May 23 2019
LGTM, although I commonly see llvm::make_unique to document that we are specifically not using the std:: one. On occasion it is actually ambiguous.
Looks like the right solution, but have you actually tried it with an empty default triple?
Drive-by: For the "dead code" did you check whether gcc emits DW_AT_start_scope? LLDB should support more than just what Clang emits.
May 22 2019
Apart from missing 'override' keywords it looks pretty straightforward. LGTM.
A few small things, and LGTM too.
May 21 2019
// FIXME: Change the following functions from anonymous namespace to static // after the minimum _MSC_VER >= 1915 (equivalent to Visual Studio version // of 15.8 or higher). Works around a bug in earlier versions.
Is there a test case for this codepath? Or should it be an assertion instead?
The helper is passed as a template parameter to a class ctor, and that instantiated class calls the helper from operator(), so I suppose maybe enough indirection through lambdas....
but this seems kind of involved for getting my builds to work.
Technically this violates the LLVM style guide which says "make anonymous namespaces as small as possible, and only use them for class declarations." (preferring static for functions) - https://llvm.org/docs/CodingStandards.html#anonymous-namespaces
To provide some missing details:
The original source gets a bogus compile-time error with Visual Studio 2017, prior to version 15.8. I have 15.2, so I need this patch to build Clang.
Our current minimum-version requirement (per CheckCompilerVersion.cmake) is Visual Studio 2015 (some specific update), which assumes all Visual Studio 2017 versions are usable. So by that criterion, we need this patch for all Visual Studio 2017 versions to be usable.
Arguably the anonymous-namespace version is the "more modern" tactic anyway, so as a long-term fix this is actually fine anyway.
May 20 2019
May 17 2019
That's a great idea, especially the "string variable" and "string substitution". I was not pleased with the name either but the only thing I thought of was regex variable which is plain wrong, I completely missed the obvious.
Naming is hard, I clearly didn't think of it right away either.
May 16 2019
There's still some inconsistency in the terminology, as clearly evidenced by the name and description of the IsNumExpr member of FileCheckPatternSubstitution. That class used to be where we'd find variables (now called pattern variables); but it has had numeric expressions crammed into it, except the comment wants to call it a substitution, and so we have "pattern" and "substitution" and "expression" all competing for clarity.
May 15 2019
Minor stuff. This solution is surprisingly simple, the main question being (and I don't have an answer) whether increasing the size of PresumedLoc is okay.
It still bothers me that MCDwarf has to know exactly when to override the target's decision to do relaxation.
May 14 2019
It sounds like inlining a function with a loop has a bug with respect to how the loop metadata is handled, and your patch merely tripped over that. Would it be reasonable to fix the inlining-loop-metadata bug separately first? And then the original patch is likely to Just Work?
Fixing one bug at a time is more in line with project practices.
LGTM once you rephrase the comment in the test.
LGTM after you add the full-stop noted below.
May 13 2019
Starting set of comments on this one. Haven't looked at everything yet.
May 10 2019