Fixed according to review comments.

Committed revision 353994 with the test cases as NFC.
Will update the patch for the remaining comments soon...

Hi Hal,
I'm actually not going to do this in the end.... I'm just going to abandon this patch.
I realized that we did actually need this type too.

Hi Hal,
Thank you for the review.
I've looked around but the only place we use u1imm is where we only have 1 bit to use in the instruction anyway so we have no way to represent -1 anyway.

This patch was committed by Galina in r352652.

Gentle ping..

Looked through this and tried a couple of things but overall it looks good.
My only comments are a couple of minor nit items.

No longer working on this.

Closed.

Addressed comments from Jinsong.

@gkistanova
Hi Galina,
Thank you for approving this.
I'm sorry but I have to change it a little bit. I just realized that the previous changeset was setting -DLLVM_ENABLE_LLD on both stage1 and stage2 builds and that won't work. We just want that option on stage2.

Addressed reviewer comments.
Limited optimization to cases where the fixed called saved regs fit in the red zone of 288 bytes.

Modified patch to completely revert rL349512.

Patch is now only for Little Endian.
Big Endian will remain PIC by default as it was before. This is due to a bug found on BE where -fsanitize=leak is not detecting leaks correctly. As Little Endian is a higher priority we will add that code first and then look at the BE issue at a later date.

Patch is now only for Little Endian.
Big Endian will remain PIC by default as it was before. This is due to a bug found on BE where -fsanitize=leak is not detecting leaks correctly. As Little Endian is a higher priority we will add that code first and then look at the BE issue at a later date.

Added the PIC version to the second test as well.
Removed the third test. It has nothing to do with this change and I should not have modified that test in the first place.

@joerg
When you say that we produce quite bad position dependent code do you mean in terms of performance or in terms of correctness? At this point I have not seen any issues with the no-PIC code. If you have an example of this bad code please share the test case.
Also, changing the default option to no-PIC does not mean that everything we do will become no-PIC. For example, the way that the TOC is handled on PPC remains position independent. However, going from PIC to no-PIC does offer a number of opportunities (for example in in-lining).
With respect to PIE I'm not sure what the difference is between PIE and static relocation models in terms of code generation. Is there any reason why you would prefer PIE in this case? Do you have an example that shows it to be better than say no-PIC?

Generally the way I decided on how to update the test depended on a couple of things:

1. If the test had this line: ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py it means that we had an auto generate test and if I felt that the test had nothing really to do with PIC or no-PIC I would just regenerate it. For example a number of tests just had addis ld differences.
2. If the test was not auto generated but it still had nothing to do with PIC / no-PIC I would just add -relocation-model=pic. Changing these tests would not get us very much and it would be a significant amount of work.
3. For tests that had something to do with PIC / no-PIC I tried to make a judgement call as to what would be more useful to keep (the PIC test or the non-PIC test). If you feel that some of these tests I should have been the other way around let me know. I know you mentioned a couple in your comment and I'll take a look at those.

Default on all Power PC platforms is now no-PIC.
If any bugs are exposed by this change we will fix them as they are exposed.

Default on all Power PC platforms is now no-PIC.
If any bugs are exposed by this change we will fix them as they are exposed.

Simplified the code further.

Updated test cases.

Test cases updated.

Simplified some of the conditionals (easier to read) and added an early exit.

I'm sorry it took so long for me to look at this review.

Addressed review comments.

Removed the custom PPCISD node and it simplified the patch considerably.

Address Review Comments

Moved condition to the correct location and added a test case.

Update patch based on reviewer comments.

I'm not 100% sure if we can remove the default option -funwind-tables for x86.
I know that using -funwind-tables prevents (or hides) this issue but it may be required for another reason that this fix does not cover. I don't actually know what the initial intention was when that default was added.
I think that someone on the x86 side would be a better judge of this.

Sorry about that. I should have added the test cases earlier.

Added test case.
Address reviewers comments.

Determined this is not the correct way to solve this problem.
Going to abandon this change.

GCC does call the exception handler correctly for this example. However, it does not (at least not that I can tell) have a default option like the one llvm uses -funwind-tables.