User Details
- User Since
- Sep 17 2014, 5:52 PM (331 w, 3 d)
Yesterday
Thu, Jan 21
Sorry about the missing files. Some hiccup while generating the diff.
Wed, Jan 20
Based on Andrea's request to use an OutputKind rather than overriding the printView method in a separate class for JSON output
Fri, Jan 15
This change is trying to use a more streamlined interface based on Andrea's feedback. I removed the printJSON method from the PipelinePrinter and the singleton object that was used to list the instructions.
Instead, each implemented view now has a <ViewName>JSON derived class that overrides the printView method. When JSON output is requested, objects of these class types are added as views. This leaves the PipelinePrinter largely unchanged.
Dec 17 2020
Apologies for the long delay, I'm finally ready to resume work on this feature. The update does the following:
Nov 19 2020
Isn't COMPILER_RT_HAS_FLOAT16 generated using the host compiler? If so, using the same flag for a compiler_rt test could fail if the host compiler supports f16 and the target compiler does not.
Nov 18 2020
This seems to fail on some buildbots: e.g. here
Nov 13 2020
The test seems to fail on some Linux buildbots, see here. Please review.
Oct 15 2020
Sep 16 2020
This commit seems to cause a test failure on some bots, e.g. here.
Aug 26 2020
Aug 25 2020
Aug 24 2020
After some consultation with @andreadb this is some more extensive refactoring:
We create a new base class InstructionView that is meant for views that deal with individual instructions (e.g. print them). The 3 members MCIP (the instruction printer), STI (subtarget info) and Source (the array of machine instructions) live there and can be accessed via getters (they could be made protected as well). Printing the instructions is effected by using a string member in the new base class (which must be mutable along with its associated stream).
Here is another proposal: We're using statics for the Instruction string and the stream to write it and return a reference to it.
The users all immediately write the string to a different stream. This should have even fewer allocations than the original code.
Aug 21 2020
Addressed review comment:
- using enumerate() instead of an explicit index variable
Aug 19 2020
Thank you Andrea!
I agree with Roman in that we should not guarantee stability of data and/or structure.
Also, changes to the output structure should always be advertised (for example, by adding a line in the release notes), so that people are always aware of it.
Addressed review comments:
- Using MutableArrayRef
- Using range-based for loops with zip
- Using default initializers with InstructionInfoViewData
Aug 18 2020
Jul 30 2020
Jul 6 2020
Jun 9 2020
Jun 1 2020
Shortly after this patch went in, we started to see intermittent failures with the unittest TUSchedulerTests.ManyUpdates. The build server (Windows) we're running it on is quite powerful and our own hand-run tests only take about 400 ms, so we don't really understand what could be happening. Any help would be appreciated.
Apr 24 2020
Apr 23 2020
LGTM, with a slight caveat regarding reporting an error for degenerate stubs of string offset sections.
Mar 25 2020
Nov 18 2019
Nov 15 2019
I'm unfortunately still getting a loop in DAGcombiner with this one (llc -mattr=+avx on linux). If you make the 1.000 in the select instr into 0.000 it finishes.
define float @test(<8 x float> *%a0) { entry: %0 = load <8 x float>, <8 x float>* %a0, align 32 %vecext = extractelement <8 x float> %0, i32 1 %cmp = fcmp oeq float %vecext, 0.000000e+00 %cond = select i1 %cmp, float 1.000000e+00, float %vecext ret float %cond }
Nov 14 2019
I applied your patch to ToT, but now I'm seeing a loop with the following IR (on linux). Seems still stuck in DAGCombine.
Sep 26 2019
For some reason, I didn't see your response until I had posted my updated. I basically implemented number 3.
- Rebased with the latest upstream changes.
- Addressed review comments as follows:
- Keeping track of stack sizes already dumped so that duplicate entries only are printed once.
- Issue a warning when a duplicate entry with a different stack size is encountered.
- Simplified code by collapsing some warning code into a lambda.
- added the appropriate test cases for the changed functionality and added one for STT_NOTYPE.
- added an early return in a case where no valid symbol is found.
Sep 25 2019
<snip>
I think this is undesirable. Perhaps you need to track whether a stack size entry for a given address has been printed yet, and skip it if it has?
Sep 24 2019
Sep 23 2019
Aug 7 2019
Addressed review comments:
This sentence in the description:
The reasons for this are unclear, so this patch adds the option to llvm-strip.
We do not add options merely for "unclear" reasons. It is because the option is a good fit for llvm-strip.
Aug 6 2019
I'm a bit unclear on what this means:
Aug 5 2019
Aug 2 2019
Addressed review comments:
Aug 1 2019
Jul 31 2019
Addressed review comments:
- renamed one of the printStackSize() functions.
- removed superfluous check for nonrelocatable object
- Used SectionRef::getName() instead of the explicit sequence to extract a section name.
- Fixed the calls to the DataExtractor() constructor to use Obj->isLittleEndian()
- Added some comments to explain the error handling policy.
- Moved a SectionName variable definition closer to the use point.
Jul 29 2019
- Undertook some refactoring of the change with the following motivation: The printStackSize* methods do mostly extracting and validating, printing the output is only a minor part. Yet they were methods of the GNUStyle class, which would have made it more difficult to implement LLVM style dumping. So I moved them mostly into the base class (DumpStyle), and delegated the printing mostly to a new method printStackSizeEntry(), which is style specific.
- Addressed the formatting comments
- Added 2 test cases (demangling and verifiying the 'not implemented' message we get from llvm-readobj.
- Explained the rationale using consumeError().
Jul 25 2019
Jun 10 2019
Jun 7 2019
Addressed review comments as suggested.
Jun 6 2019
May 22 2019
May 14 2019
Apr 19 2019
LGTM
@danielcdh @wolfgangp -- Would switching to line 0 locations for hoisted instructions have an adverse effect on Sample PGO?
Apr 15 2019
Apr 12 2019
Feb 21 2019
So this basically prevents the debugger from displaying an inconsistent program state when some of the sideeffects from a line preceding its current stopping point have not been completed yet. Makes sense to me. One minor concern: If the sunk instruction does not get sunk past the next source line, we may create some unneeded location list entries, e.g.:
Feb 11 2019
Feb 4 2019
Feb 1 2019
Jan 31 2019
Jan 30 2019
Jan 29 2019
- Addressed review comments on code structure and clarifying comments.
Changed the function names from isSpillInstruction/isRestoreInstruction to getSpillSize/getRestoreSize.
Jan 28 2019
- Added methods to MachineInstr to recognize Spills and restores and have AsmPrinter and LIvedebugValues use them
- Unified tranferSpill and transferRestore functions.
- Addressed other minor review comments.
LGTM