- User Since
- Sep 17 2014, 5:52 PM (401 w, 1 d)
Wed, May 25
Addressed review comments.
Mon, May 23
Added a unit test to make sure the move constructor and the move assignment op of MDOperand adjust tracking info.
Sat, May 21
Use a better way to create a distinct node from an existing uniqued one and simplify dealing with AppendUnique module flags.
Use the default constructor for LargeStorageVector followed by a resize instead of the constructor using a numOps parameter. Doing the latter requires the copy constructor for MDOperand.
Only define the move constructor and move assignment operator. Use retrack() instead of relying on the destructor to untrack the source op.
Thu, May 19
This patch depends on D125998. When appending module flags to the module flags of another module (probably during module linking) we want to append the operands to the destination module's MDTuple instead of creating new ones. This should fix issue 51893.
You mentioned that phabricator reviews can be linked. I'm having trouble finding out how.
NM, found it.
Fri, May 13
Thu, May 12
Tue, May 3
Apr 27 2022
Apr 16 2022
Seems to be fine now. Thanks.
Apr 15 2022
Hi, there seems to be a unit test failure, for example here.
Mar 29 2022
This is a breakdown of MDNodes by number of operands using a bootstrap and a couple of other internal builds (-g -O2). The second column gives the percentage of MDnodes with the number of operands in the first column.
99.9 percent of all nodes have 15 operands or fewer. Almost half have 2 operands.
Mar 25 2022
I'm finally getting around to take a stab at this. One thing in particular is giving me trouble:
Feb 2 2022
Thanks for looking into this.
Jan 27 2022
Jan 10 2022
Dec 14 2021
Hi. This patch is causing a couple of test failures on one of our internal bots which is still running Ubuntu 18.04. Do you have any idea what could be causing it? I'm posting the test output:
Dec 13 2021
Oct 12 2021
Oct 6 2021
This is causing problems with gcc versions that don't have cet.h yet. I think cet.h wasn't added until gcc 8.
Oct 5 2021
Oct 4 2021
Sep 30 2021
Sep 29 2021
Sep 17 2021
Aug 10 2021
Jul 14 2021
Addressed the review comments:
- added an assert that verifies that either the addend or LocData is 0
- renamed the relocation section into .rela.xxx
- deleted some unnecessary section properties
Jul 13 2021
Ping. Any comments on this more RISCV-specific approach?
Jul 1 2021
Ignore LocData for RELA relocations except for RISCV, which uses both LocData and Addend.
Jun 30 2021
Jun 29 2021
Jun 28 2021
Jun 10 2021
If nobody has any more objections, I'll commit this change, then. Please let me know if you think otherwise.
Jun 9 2021
Jun 8 2021
Given the assessment on GlobalOpt, removed the LangRef changes and updated the subject line.
Jun 7 2021
Following the suggestion to define an order of initialization for the entries in llvm.global_ctors and llvm.global_dtors this is mainly a documentation change, as well as a simple reversed emission of global_ctors/dtors entries when InitArray is not used.
3 test cases are affected, 2 of them just by a reversed order of emission of priority-suffixed sections. I added a couple of entries to the third test case to verify in-order emission of entries with equal priority.
Jun 2 2021
Jun 1 2021
Apr 29 2021
Mar 25 2021
Mar 10 2021
Mar 9 2021
Feb 16 2021
Ping. Just wondering if there are any new insights on the issue reported in PR48030.
Jan 25 2021
Jan 22 2021
Jan 21 2021
Sorry about the missing files. Some hiccup while generating the diff.
Jan 20 2021
Based on Andrea's request to use an OutputKind rather than overriding the printView method in a separate class for JSON output
Jan 15 2021
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