- User Since
- Aug 26 2015, 2:20 PM (87 w, 3 d)
Fri, Apr 28
move the pass till the end of the optimizations.
Update the patch to have a separate pass to handle live range shrinking within BB.
Thu, Apr 27
Wed, Apr 26
Thu, Apr 20
set initial value for local variables.
Wed, Apr 19
updated in NFC commit r300753.
Will have separate patch to address other concerns.
Updated the logic and remove the assertion. Add a unittest to cover the symbolization of the padding zone.
Reverted as this breaks buildbot: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/3369
Tue, Apr 18
Now the assertion is enabled to ensure the behavior does not change. PTAL. Thanks!
update the code to ignore 0-sized ranges.
hold on... the assertion actually triggers... looking into why...
remove unintended change...
update with more comments.
Mon, Apr 17
Fri, Apr 14
Thu, Apr 13
Tue, Apr 11
Thanks for the explanation. This makes sense. The reasons that we try to avoid IntrinsicInst is 2 fold:
Thanks for explaining. My understanding is that memcpy will introduce new basic block, which will share the same discriminator with other basic block without this patch. As a result, that basic block is incorrectly annotated so that the block placement is suboptimal. If my understanding is correct, could you include a that in the unittest?
Mon, Apr 10
I don't quite understand why you want to set a new discriminator for memcpy builtin. What optimization would it enable? For normal function calls, we need to have discriminator to distinguish callsites in the same BB so that we can annotate the inlined callee correctly. But for the memcpy case, looks like adding a new discriminator does not help down-stream optimizations like inlining?
Fri, Apr 7
Thu, Apr 6
Tue, Apr 4
remove the support for PMADDUBSW as it cannot handle overflow case.
Mar 31 2017
rebase and update
Mar 24 2017
Mar 23 2017
Mar 22 2017
Updated the patch to change for the cold prefix tool.
Mar 21 2017
add more test