- May 14, 2013
-
-
Kai Nacke authored
The personality function is user defined and may have an arbitrary result type. The code assumes always i8*. This results in an assertion failure if a different type is used. A bitcast to i8* is added to prevent this failure. Reviewed by: Renato Golin, Bob Wilson llvm-svn: 181802
-
Derek Schuff authored
ARM FastISel is currently only enabled for iOS non-Thumb1, and I'm working on enabling it for other targets. As a first step I've fixed some of the tests. Changes to ARM FastISel tests: - Different triples don't generate the same relocations (especially movw/movt versus constant pool loads). Use a regex to allow either. - Mangling is different. Use a regex to allow either. - The reserved registers are sometimes different, so registers get allocated in a different order. Capture the names only where this occurs. - Add -verify-machineinstrs to some tests where it works. It doesn't work everywhere it should yet. - Add -fast-isel-abort to many tests that didn't have it before. - Split out the VarArg test from fast-isel-call.ll into its own test. This simplifies test setup because of --check-prefix. Patch by JF Bastien llvm-svn: 181801
-
Bill Schmidt authored
The changes to CR spill handling missed a case for 32-bit PowerPC. The code in PPCFrameLowering::processFunctionBeforeFrameFinalized() checks whether CR spill has occurred using a flag in the function info. This flag is only set by storeRegToStackSlot and loadRegFromStackSlot. spillCalleeSavedRegisters does not call storeRegToStackSlot, but instead produces MI directly. Thus we don't see the CR is spilled when assigning frame offsets, and the CR spill ends up colliding with some other location (generally the FP slot). This patch sets the flag in spillCalleeSavedRegisters for PPC32 so that the CR spill is properly detected and gets its own slot in the stack frame. llvm-svn: 181800
-
Jyotsna Verma authored
the jump instructions in the form of taken/not-taken hint. llvm-svn: 181799
-
Sergey Matveev authored
llvm-svn: 181798
-
Jyotsna Verma authored
llvm-svn: 181797
-
Sergey Matveev authored
llvm-svn: 181796
-
Daniel Malea authored
Fix inline stepping test case on Linux because Thread::ThreadStoppedForAReason ignored virtual steps. - add IsVirtualStep() virtual function to ThreadPlan, and implement it for ThreadPlanStepInRange - make GetPrivateStopReason query the current thread plan for a virtual stop to decide if the current stop reason needs to be preserved - remove extra check for an existing process in GetPrivateStopReason llvm-svn: 181795
-
Sergey Matveev authored
llvm-svn: 181793
-
Tom Stellard authored
Patch by: Alex Deucher Reviewed-by:
Tom Stellard <thomas.stellard@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> NOTE: This is a candidate for the 3.3 branch. llvm-svn: 181792
-
Sergey Matveev authored
llvm-svn: 181791
-
Evgeniy Stepanov authored
llvm-svn: 181790
-
Ashok Thirumurthi authored
llvm-svn: 181789
-
Duncan Sands authored
-DLLVM_ENABLE_THREADS=false. llvm-svn: 181788
-
Sergey Matveev authored
llvm-svn: 181787
-
Sergey Matveev authored
llvm-svn: 181786
-
Rafael Espindola authored
GCC declares __clear_cache in the gnu modes (-std=gnu++98, -std=gnu++11), but not in the strict modes (-std=c++98, -std=c++11). This patch declares it and therefore fixes the build when using one of the strict modes. llvm-svn: 181785
-
Rafael Espindola authored
Current gcc's produce an error if __clear_cache is anything but __clear_cache(char *a, char *b); It looks like we had just implemented a gcc bug that is now fixed. llvm-svn: 181784
-
Benjamin Kramer authored
llvm-svn: 181783
-
Benjamin Kramer authored
llvm-svn: 181782
-
Benjamin Kramer authored
There is no clangRewrite.a. llvm-svn: 181781
-
Manuel Klimek authored
llvm-svn: 181780
-
Daniel Jasper authored
llvm-svn: 181779
-
Daniel Jasper authored
We have been assuming that CharSourceRange::getTokenRange() by itself expands a range until the end of a token, but in fact it only sets IsTokenRange to true. Thus, we have so far only considered the first character of the last token to belong to an unwrapped line. This did not really manifest in symptoms as all edit integrations expand ranges to fully lines. llvm-svn: 181778
-
Richard Sandiford authored
llvm-svn: 181777
-
Michel Danzer authored
Reviewed-by:
Christian König <christian.koenig@amd.com> llvm-svn: 181775
-
Richard Sandiford authored
Forgot to svn add these... llvm-svn: 181774
-
Richard Sandiford authored
The GNU assembler treats things like: brasl %r14, 100 in the same way as: brasl %r14, .+100 rather than as a branch to absolute address 100. We implemented this in LLVM by creating an immediate operand rather than the usual expr operand, and by handling immediate operands specially in the code emitter. This was undesirable for (at least) three reasons: - the specialness of immediate operands was exposed to the backend MC code, rather than being limited to the assembler parser. - in disassembly, an immediate operand really is an absolute address. (Note that this means reassembling printed disassembly can't recreate the original code.) - it would interfere with any assembly manipulation that we might try in future. E.g. operations like branch shortening can change the relative position of instructions, but any code that updates sym+offset addresses wouldn't update an immediate "100" operand in the same way as an explicit ".+100" operand. This patch changes the implementation so that the assembler creates a "." label for immediate PC-relative operands, so that the operand to the MCInst is always the absolute address. The patch also adds some error checking of the offset. llvm-svn: 181773
-
Richard Sandiford authored
Marking instructions as isAsmParserOnly stops them from being disassembled. However, in cases where separate asm and codegen versions exist, we actually want to disassemble to the asm ones. No functional change intended. llvm-svn: 181772
-
Richard Sandiford authored
The SystemZ port currently relies on the order of the instruction operands matching the order of the instruction field lists. This isn't desirable for disassembly, where the two are matched only by name. E.g. the R1 and R2 fields of an RR instruction should have corresponding R1 and R2 operands. The main complication is that addresses are compound operands, and as far as I know there is no mechanism to allow individual suboperands to be selected by name in "let Inst{...} = ..." assignments. Luckily it doesn't really matter though. The SystemZ instruction encoding groups all address fields together in a predictable order, so it's just as valid to see the entire compound address operand as a single field. That's the approach taken in this patch. Matching by name in turn means that the operands to COPY SIGN and CONVERT TO FIXED instructions can be given in natural order. (It was easier to do this at the same time as the rename, since otherwise the intermediate step was too confusing.) No functional change intended. llvm-svn: 181771
-
Daniel Jasper authored
Before (in styles that allow it), clang-format would not merge an if statement onto a single line, if only the second line was format (e.g. in an editor integration): if (a) return; // clang-format invoked on this line. With this patch, this gets properly merged to: if (a) return; // ... llvm-svn: 181770
-
Richard Sandiford authored
The SystemZ port currently relies on the order of the instruction operands matching the order of the instruction field lists. This isn't desirable for disassembly, where the two are matched only by name. E.g. the R1 and R2 fields of an RR instruction should have corresponding R1 and R2 operands. The main complication is that addresses are compound operands, and as far as I know there is no mechanism to allow individual suboperands to be selected by name in "let Inst{...} = ..." assignments. Luckily it doesn't really matter though. The SystemZ instruction encoding groups all address fields together in a predictable order, so it's just as valid to see the entire compound address operand as a single field. That's the approach taken in this patch. Matching by name in turn means that the operands to COPY SIGN and CONVERT TO FIXED instructions can be given in natural order. (It was easier to do this at the same time as the rename, since otherwise the intermediate step was too confusing.) No functional change intended. llvm-svn: 181769
-
Manuel Klimek authored
This library supports all the features of the compile-time based ASTMatcher library, but allows the user to specify and construct the matchers at runtime. It contains the following modules: - A variant type, to be used by the matcher factory. - A registry, where the matchers are indexed by name and have a factory method with a generic signature. - A simple matcher expression parser, that can be used to convert a matcher expression string into actual matchers that can be used with the AST at runtime. Many features where omitted from this first revision to simplify this code review. The main ideas are still represented in this change and it already has support working use cases. Things that are missing: - Support for polymorphic matchers. These requires supporting code in the registry, the marshallers and the variant type. - Support for numbers, char and bool arguments to the matchers. This requires supporting code in the parser and the variant type. - A command line program putting everything together and providing an already functional tool. Patch by Samuel Benzaquen. llvm-svn: 181768
-
Manuel Klimek authored
This fixes indentation where there are for example multiple closing parentheses after a string literal, and where those parentheses run over the end of the line. During testing this revealed a bug in the implementation of breakProtrudingToken: we don't want to change the state if we didn't actually do anything. llvm-svn: 181767
-
Daniel Jasper authored
- Remove free variables - Add function clang-format-buffer, e.g. for before-save-hooks - Wrap restoring windows in an unwind-protect Patch by Stephen Gildea! llvm-svn: 181766
-
Tim Northover authored
llvm-svn: 181765
-
Daniel Jasper authored
Before: A<sizeof (*x)> a; After: A<sizeof(*x)> a; llvm-svn: 181764
-
Kostya Serebryany authored
llvm-svn: 181763
-
Tim Northover authored
According to libgcc document __clear_cache takes two char* pointers. I suspect GCC's actual behaviour is more subtle than that, but char* should clearly be preferred to void*. llvm-svn: 181762
-
Patrik Hagglund authored
[-Wconversion-null], introduced in r181326. llvm-svn: 181761
-