Summary:
Because GCC doesn't use $1 for code generation, inline assembly code can use $1 without having to add it to the clobbers list.
LLVM, on the other hand, does not shy away from using $1, and this can cause conflicts with inline assembly which assumes GCC-like code generation.
A solution to this problem is to make Clang automatically clobber $1 for all MIPS inline assembly.
This is not the optimal solution, but it seems like a necessary compromise, for now.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6638
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224428 91177308-0d34-0410-b5e6-96231b3b80d8
'R' An address that can be sued in a non-macro load or store.
This patch includes a positive test case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176453 91177308-0d34-0410-b5e6-96231b3b80d8
clang itself. This dates back to clang's early days and while it looks like
some of it is still used (for kext for example), other parts are probably dead.
Remove the -ccc-clang-archs option and associated code. I don't think there
is any remaining setup where clang doesn't support an architecture but it can
expect an working gcc cross compiler to be available.
A nice side effect is that tests no longer need to differentiate architectures
that are included in production builds of clang and those that are not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165545 91177308-0d34-0410-b5e6-96231b3b80d8
just trying to show it did not crash and burn.
This patch checks that the resultant .ll contents
are correct.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162249 91177308-0d34-0410-b5e6-96231b3b80d8
Toma Tabacu