- User Since
- Dec 9 2012, 11:41 PM (228 w, 6 d)
Fri, Apr 28
Thu, Apr 27
@majnemer thats the idea :-). Passing either triple to clang would give the right behaviour (clang will normalize the triple before passing it to cc1).
Yes, the idea is that the textual IR uses the correct triple, unless it is overidden at the command line.
Mon, Apr 24
Why not always replace the extension? Windows doesnt require the .exe suffix IIRC.
Is this to actually get the correct GCC search dir? Your test doesnt really test anything AFAICT, as it is just invoking clang with a target that it would accept anyways.
I think that you should mutate the environment in the canonicalisation phase of the triple. That will allow you to use armv7-suse-linux-gnueabi and armv7-suse-linux-gnueabihf in the frontend, but have the backend always get armv7-suse-linux-gnueabihf.
Fri, Apr 21
Thu, Apr 20
Wed, Apr 19
This would ideally wait for the change that @jbcoe has in the works to enable python 3, but the change itself is fine.
Thanks for doing this cleanup!
I think it would've been nice to split this up into the changes for map/filter rather than group it together. But sure, this looks reasonable.
Please add a test case. The change itself looks reasonable.
Tue, Apr 18
This is opt-out by default, so it shouldn't have any impact on users by default. When building for tooling, this should allow smaller builds for those.
Fri, Apr 14
Thu, Apr 13
Minor comments on the test, but LGTM otherwise.
Fri, Apr 7
Thu, Apr 6
Wed, Apr 5
Please address the issue that @rengolin pointed out. There is no reason to have an explicit triple here, as the test is agnostic. Just drop the nop in the macro.
Mon, Apr 3
Sure, using the same flags sounds reasonable.
Mar 29 2017
Mar 28 2017
Mar 26 2017
I think you misunderstood what I meant. I meant that you should change the mangling scheme to put the symbol into a C++ __Swift::swift_cc namespace since that is reserved. That would mean that this enumeration would not be touched at all.
What happens when you try building it in tree?
I've sent an email to Microsoft to add this to their scheme. In the mean time, if you want to support this, we should namespace the symbol to __swift::swift_cc:: instead of the usual mangling. That would be compatible with their tools and allow us to use the custom calling convention.
Mar 24 2017
Mar 23 2017
As previously mentioned, if this absolutely requires that the file not be treated opaquely, then we should be putting this functionality into another tool. Perhaps llvm-bc would be a good home for this. I'd really rather LLVM-strings be kept simple and treat all input as opaque.
Mar 22 2017
Some of the implementations are not going to build in thumb1 mode, but would in thumb2, which is why we didnt do this uniformly. I think we need to preserve that, or rewrite the functions.
I think that @chandlerc is suggesting making it a CMake option (see the option function in CMake) to provide documentation for this for users. I think that is a pretty reasonable ask, as it aids in discoverability of this.
Mar 21 2017
I think that the idea that you propose is good, however, I think that may be better to do as a follow up. This would get the immediate benefit for the tooling, and we can work out a nicer way to expose the information to the other users. Making it something which each app does means that we would need to change all the apps as well, which would be a much larger change.
Mar 20 2017
Mar 14 2017
I really think that we shouldnt introduce the USE_* macros, opting to re-organise the code (separate change) and then using the appropriate macros. It avoids the layer of indirection which makes it easier for others to follow what is going on.
Mar 8 2017
Mar 7 2017
Not sure if I see the movement as being a real improvement. However, it is no worse than before, and not having the explicit list of targets is a huge win.
Mar 2 2017
Feb 20 2017
Feb 19 2017
Feb 18 2017
Feb 17 2017
Ah, I had missed the -verify option on the test. Yes, that makes sense. Ternary may have flowed the conditional code better. Do you need someone to commit this on your behalf?
Feb 16 2017
I think Im misunderstanding something. How does the test actually test what you are changing?
Feb 15 2017
Please add a test for this.
Feb 13 2017
Feb 12 2017
Feb 11 2017
*sigh* Thanks for fixing this. Please ask @hans to cherry-pick this to 4.0 as well.
Feb 10 2017
This was committed, sorry, dont have the revision off hand.