Thank you for the review. I will commit the patch with the suggested change shortly.
Jan 8 2019
Jan 3 2019
Dec 7 2018
Dec 3 2018
Apologies for the breakage. This was supposed to be an AArch64 test but the triple is incorrect. Should be fixed in rL348111.
Nov 29 2018
Nov 26 2018
Nov 14 2018
Nov 8 2018
Nov 7 2018
Updated patch improves the RegAllocFast part and adds more testing for it. InlineSpiller has no new changes.
Oct 4 2018
No worries, thanks.
Sep 19 2018
Thanks for having a look at this patch. Updated version addresses the review comments.
Sep 11 2018
Sep 10 2018
Aug 14 2018
Thanks for the explanation of this idea. Updated patch goes in that direction and provides a prototype of this approach. The implementation is done in Fast Register Allocator (which has its own spiller code) and in InlineSpiller (used by the other LLVM allocators: Basic, Greedy, PBQP).
Jul 26 2018
Thanks for having a look at this patch.
Jul 24 2018
Jul 19 2018
This is possibly problematic when the register pressure is high because ThumbRegisterInfo::saveScavengerRegister() currently also tries to make use of high register r12.
Also, the constant islands pass can clobber lr. But given the only way to end up with an "hGPR" register class is inline asm, we could probably work around this issue by excluding ip/lr from allocation order for hGPR.
That said, if we ever want to make the high registers generally allocatable in Thumb1 mode, this patch probably isn't the right solution; instead, we should make the register allocator insert the copy, so we aren't forced to scavenge a register later.
Jul 16 2018
Jul 4 2018
Jul 2 2018
Thanks for the explanation. This does not cause any immediate problem for us but it is unfortunate that a simple assignment of a constant now appears to be split between two lines. Hopefully it will be potentially possible to implement some improvement for this case in the future.
Jun 29 2018
Apr 19 2018
Oct 11 2017
Landed as r315444. Closing manually because I forgot to include "Differential Revision: ..." in the commit message.
Thanks, will commit shortly.
Oct 10 2017
Updated patch contains the following changes:
- Remove comments for DataExtractor::GetMaxU32() and GetMaxU64() from DataExtractor.cpp and keep only the Doxygen ones in the header file.
- Restore assertion for byte_size == 0 in GetMaxU32() and GetMaxU64(), change the assert text from "unhandled case" to "invalid byte_size" and replace assert() by lldbassert().
- Update Doxygen documentation for GetMaxU32(), GetMaxU64(), GetMaxS64(), GetMaxU64Bitfield() and GetMaxS64Bitfield() to say that byte_size must be in interval [1,4/8] and remove that the methods return 0 if byte_size is bigger than 4/8 because that no longer holds. The patch retains the behaviour that LLDB does not crash in such cases but the returned value can be arbitrary. Note: This is something that I am not certain if I addressed properly. It seems to me this should be ok because the code now uses lldbassert() and so there will be always some error that something went wrong. An alternative is to add extra code that checks for byte_size > 4/8 and returns 0 in such cases. Please let me know if that would be preferred.
- Enable GetMaxU64_unchecked() to also handle any byte_size in range [1,8] and add testing for this method in DataExtractorTest.cpp.
Oct 4 2017
Oct 3 2017
Thank you for the initial review.
Sep 29 2017
Jul 12 2017
Jan 29 2017
Feb 29 2016
Jan 15 2016
Ping. I would still like to address this problem. Could I please get a review on the last version of the patch?
Updated patch deletes the error() call after LTOModule::createFromFile() from llvm-lto because any error from this function should go through the diagnostic handler in llvm-lto which will exit the program.
Thank you for looking at this patch. I will update the patch to delete the error() call after LTOModule::createFromFile() from llvm-lto.
Jan 12 2016
Dec 11 2015
Updated patch adds more tests and fixes a problem introduced in the previous revision where templates taking __val_expr were not correctly protected by SFINAE from immediate context (it introduced same problem with explicit template parameters that I am trying to solve).
Nov 18 2015
I am not sure if I understand the comment about [184.108.40.206] correctly. It is not clear to me how this part of the standard prevents the user from specifying explicit template parameters for standard functions. It seems odd that the standard would disallow, for example, to use std::max<double>(1, 2.0).
Nov 16 2015
Oct 25 2015
Thank you for having a look at this patch. I should get to updating it as requested soon. Apologies for the delay.
Oct 3 2015
It would be probably better if the patch changed the original templates to take only __val_expr as there is now no need for them to match valarray too. This should be a simple change but requires additional tests so I will wait for initial feedback that this approach is preferred.
Sep 30 2015
Jul 6 2015
Updated patch fixes formatting problems and corrects the debugging output.
Improve decoding options for non-orthogonal instructions
Mar 16 2015
Mar 2 2015
Updated patch adds a check that the instruction coming in DecodeSystemPStateInstruction() is really MSR (immediate) (MSRpstate in LLVM), which means it can be interpreted as the extended MSR if pstatefield is not allocated. I think it would be a logical error if the method was called for non-MSR (immediate) instructions so the code asserts this condition (instead of returning Fail).
Feb 17 2015
Thank you Renato for having a look at this patch.
Any feedback on this patch? I realize it is an ugly one but I would appreciate any hints how it could be done in a cleaner way.
Jan 26 2015
Sep 1 2014
Aug 29 2014
Aug 20 2014
Aug 1 2014
Jul 28 2014