Page MenuHomePhabricator

JohnReagan (John Reagan)
User

Projects

User does not belong to any projects.

User Details

User Since
Oct 9 2018, 12:17 PM (40 w, 3 h)

Recent Activity

May 16 2019

JohnReagan added a comment to D61690: [X86] Deduplicate symbol lowering logic, NFC.

I like that you combined it for ease of use. We have OpenVMS-specific changes for our out-of-tree cross-compilers (based on 3.4.2) and it was even worse back then. Having it in one place makes it easier for us. We're currently rebasing for native compilers based on 8.0.0 but will probably rebase again quickly.

May 16 2019, 11:57 AM · Restricted Project

May 8 2019

JohnReagan added inline comments to D61325: Treat a narrowing PtrToInt like Trunc when generating asm.
May 8 2019, 6:47 AM · Restricted Project

Apr 12 2019

JohnReagan added a comment to D60169: Proposed refactoring for lib/Target/X86 to remove layering issue.

Yes, D60597 feels better if that helps in this case as well.

Apr 12 2019, 2:57 AM

Apr 8 2019

JohnReagan added a comment to D60169: Proposed refactoring for lib/Target/X86 to remove layering issue.

Other than better Feng Shui, is there a problem you are trying to solve? Is it a building issue?

Apr 8 2019, 10:49 PM

Feb 19 2019

JohnReagan added a comment to D58266: [MC] Sort DWARF FDEs by the associated CIE before emitting them..

I asked my local expert for an opinion.

Feb 19 2019, 11:39 AM · Restricted Project

Feb 6 2019

JohnReagan added a comment to D57810: MC/ELF: Allow targets to set ABI version.

Awesome. I have a out-of-tree change similar to this but I won't be rebasing for another 6 months or so. You've saved me the work. :)

Feb 6 2019, 5:59 AM · Restricted Project

Dec 13 2018

JohnReagan added a comment to D54487: Implement llvm.commandline named metadata.

LGTM2

Dec 13 2018, 5:57 AM

Dec 12 2018

JohnReagan added inline comments to D54487: Implement llvm.commandline named metadata.
Dec 12 2018, 11:24 AM

Dec 10 2018

JohnReagan added a comment to D54487: Implement llvm.commandline named metadata.

I'll ask the larger question of why did you pick ".LLVM.command.line" as the section name? While distasteful, there might be existing scripts that do things like:

Dec 10 2018, 9:22 AM

Dec 5 2018

JohnReagan added a comment to D55263: [CodeGen][ExpandMemcmp] Add an option for allowing overlapping loads..

One of my coworkers did an informal test last year and saw that newer Intel CPUs optimization of REP-string-op-instruction was faster than using SSE2 (he used large data sizes, not anything in the shorter ranges this patch deals with). Is that something that should be looked at? (or has somebody done that examination already)

Dec 5 2018, 12:57 PM
JohnReagan added inline comments to D55263: [CodeGen][ExpandMemcmp] Add an option for allowing overlapping loads..
Dec 5 2018, 12:53 PM

Nov 14 2018

JohnReagan added a comment to D54487: Implement llvm.commandline named metadata.

Doesn't clang already has -grecord-gcc-switches option (https://clang.llvm.org/docs/ClangCommandLineReference.html#debug-information-flags) ?

Nov 14 2018, 9:28 AM
JohnReagan added a comment to D54487: Implement llvm.commandline named metadata.

I know you are just trying to match gcc behavior, but do you know why they use SHT_PROGBITS instead of something like SHT_NOTE for the information? On OpenVMS, we use .note entries to record compilation date/time, compiler version, command line, etc. information that is later used by our linker to print out detail link maps. Or is the intention that the information get propagated all the way to the final executable or shared library?

I don't have a good answer as to why GCC decided to use SHT_PROGBITS, and you're correct that I simply followed their lead. I think SHT_NOTE seems more appropriate, although at AMD we do want to propagate the section to the final executable/shared object; are the two incompatible? It seems fine if tools like strip remove the section.

Nov 14 2018, 9:17 AM

Nov 13 2018

JohnReagan added a comment to D54487: Implement llvm.commandline named metadata.

I know you are just trying to match gcc behavior, but do you know why they use SHT_PROGBITS instead of something like SHT_NOTE for the information? On OpenVMS, we use .note entries to record compilation date/time, compiler version, command line, etc. information that is later used by our linker to print out detail link maps. Or is the intention that the information get propagated all the way to the final executable or shared library?

Nov 13 2018, 12:18 PM
JohnReagan added a comment to D54327: Adding debug info to support Fortran (part 3).

I don't understand the need for the "common alpha" global variable.

It's not strictly required to have it explicitly named. Our implementation allocates a COMMON block as an "untyped" block of memory and each subprogram can, of course, remap the storage units to its own list of variable names. The DW_TAG_common_block does require a DW_AT_location, and the !DIGlobalVariable fulfills that requirement.

Nov 13 2018, 8:10 AM · Restricted Project, debug-info

Nov 12 2018

JohnReagan added a comment to D54420: Fix .cfi_restore with register numbers > 64.

Ah, thanks for finding this. We were just noticing this on our OpenVMS port since we also use platform-registers way up in the 16352-16383 range.

Nov 12 2018, 6:38 AM

Nov 9 2018

JohnReagan added a comment to D54327: Adding debug info to support Fortran (part 3).

I don't understand the need for the "common alpha" global variable. For VMS Fortran on Itanium (not LLVM), we generate the following DWARF for

Nov 9 2018, 10:57 AM · Restricted Project, debug-info

Nov 8 2018

JohnReagan added a comment to D54114: Adding debug info to support Fortran (part 2).

[Sorry for the delay, my Dad broke a hip and I had to travel to Tennessee.]

Nov 8 2018, 9:19 AM · Restricted Project, debug-info

Nov 5 2018

JohnReagan added inline comments to D54114: Adding debug info to support Fortran (part 2).
Nov 5 2018, 1:12 PM · Restricted Project, debug-info
JohnReagan added a comment to D54114: Adding debug info to support Fortran (part 2).

As I commented in the dev email list, these "Fortran" features are actually useful for other languages. We use similar DWARF for Pascal "schema types", BASIC string types, etc. on OpenVMS Itanium and we'll want to leverage all of these for our x86 target. I suggested that the names be make more neutral or folded into the matching metadata tag. I'll give inline comments next.

Nov 5 2018, 12:45 PM · Restricted Project, debug-info
JohnReagan added a comment to D54043: Adding debug info to support Fortran (part 1).

While I normally would recommend NOT encoding the language name in the constants (I'll be making that suggestion in "part 2" in just a bit), these symbols are clearly Fortran-only (you OR in bit DIFlagFortran 30). The text in the DWARF4 standard also makes the same case but doesn't come out and say Fortran-only but just "These attributes are not relevant for languages that do not support similar keywords or syntax." So should they be named DIFlagFortranPure, DIFlagFortranElemental, DIFlagFortranRecursive or is that too heavy handed?

Nov 5 2018, 12:04 PM · Restricted Project, debug-info
JohnReagan added a comment to D54016: [X86] don't allow X86_64 PIC mode addresses to be used as immediates.

Yes I see. Thanks for double checking.

Nov 5 2018, 10:20 AM

Nov 2 2018

JohnReagan added a comment to D54016: [X86] don't allow X86_64 PIC mode addresses to be used as immediates.

While that seems like a place to change, I would have thought that the code just a little farther down would have caught this....

Nov 2 2018, 8:18 AM

Oct 22 2018

JohnReagan added inline comments to D46878: Add DW_AT_linkage_name for DW_TAG_labels.
Oct 22 2018, 11:38 AM

Oct 20 2018

JohnReagan added inline comments to D46878: Add DW_AT_linkage_name for DW_TAG_labels.
Oct 20 2018, 12:43 PM