- Dec 26, 2013
-
-
Venkatraman Govindaraju authored
llvm-svn: 198029
-
Venkatraman Govindaraju authored
llvm-svn: 198028
-
- Dec 25, 2013
-
-
Simon Atanasyan authored
consider to generate stubs for mips16 hard-float mode. The patch reviewed by Reed Kotler. llvm-svn: 198019
-
Elena Demikhovsky authored
llvm-svn: 198013
-
Zoran Jovanovic authored
llvm-svn: 198010
-
Zoran Jovanovic authored
llvm-svn: 198009
-
Elena Demikhovsky authored
llvm-svn: 198008
-
Hao Liu authored
E.g. the codegen result is fmls v1.2s, v0.2s, v2.s[3] which is expected to be fmls v0.2s, v1.2s, v2.s[3] llvm-svn: 198001
-
- Dec 24, 2013
-
-
Richard Sandiford authored
llvm-svn: 197986
-
Richard Sandiford authored
...namely LOAD AND ADD, LOAD AND AND, LOAD AND OR and LOAD AND EXCLUSIVE OR. LOAD AND ADD LOGICAL isn't really separately useful for LLVM. I'll look at adding reusing the CC results in new year. llvm-svn: 197985
-
Richard Sandiford authored
llvm-svn: 197984
-
Elena Demikhovsky authored
llvm-svn: 197981
-
Hao Liu authored
llvm-svn: 197969
-
Kevin Qin authored
DAG.getVectorShuffle() doesn't always return a vector_shuffle node. If mask is the exact sequence of it's operand(For example, operand_0 is v8i8, and the mask is 0, 1, 2, 3, 4, 5, 6, 7), it will directly return that operand. So a check is added here. llvm-svn: 197967
-
Kevin Qin authored
This failure caused by improper condition when lowering shuffle_vector to scalar_to_vector. After this patch NEON_VDUP with v1i64 will not be generated. llvm-svn: 197966
-
Ana Pazos authored
Check for single use of fmul node in fused multiply patterns to allow generation of fused multiply add/sub instructions. Otherwise fmul operation ends up being repeated more than once which does not help peformance on targets with only one MAC unit, as for example cortex-a53. llvm-svn: 197929
-
Ana Pazos authored
The correct pattern matching should be: - fnmadd is (-Ra) + (-Rn)*Rm which should be matched as: fma (fneg node:$Rn), node:$Rm, (fneg node:$Ra) and as (f32 (fsub (f32 (fneg FPR32:$Ra)), (f32 (fmul FPR32:$Rn, FPR32:$Rm)))) - fnmsub is (-Ra) + Rn*Rm which should be matched as fma node:$Rn, node:$Rm, (fneg node:$Ra) and as (f32 (fsub (f32 (fmul FPR32:$Rn, FPR32:$Rm)), FPR32:$Ra)))) llvm-svn: 197928
-
- Dec 23, 2013
-
-
Adrian Prantl authored
(optional) DWARF sections, so compiling with -g does not result in different code being generated. rdar://problem/15623193 llvm-svn: 197922
-
Saleem Abdulrasool authored
The bkpt mnemonic has an implicit immediate constant of 0 unless otherwise specified. Add an instruction alias for the unvalued breakpoint mnemonic to treat it as a 0. This improves compatibility with GNU AS. Signed-off-by:
Saleem Abdulrasool <compnerd@compnerd.org> llvm-svn: 197913
-
- Dec 22, 2013
-
-
Roman Divacky authored
llvm-svn: 197878
-
Elena Demikhovsky authored
llvm-svn: 197876
-
Roman Divacky authored
llvm-svn: 197875
-
- Dec 20, 2013
-
-
Lang Hames authored
Found by inspection by Julien Lerouge. Thanks Julian! llvm-svn: 197833
-
Timur Iskhodzhanov authored
Reviewed at http://llvm-reviews.chandlerc.com/D2445 llvm-svn: 197826
-
Roman Divacky authored
llvm-svn: 197824
-
Zoran Jovanovic authored
llvm-svn: 197815
-
Richard Sandiford authored
If the extension of a loaded value is compared against zero and used in other arithmetic, InstCombine will change the comparison to use the unextended load. It's also possible that the comparison could be against the unextended load from the outset. In DAG form this becomes a truncation of an extending load. We want to strip the truncation if possible so that we can use load-and-test instructions. llvm-svn: 197804
-
Richard Sandiford authored
The handling of ANY_EXTEND and ZERO_EXTEND was too strict. In this context we can treat ZERO_EXTEND in much the same way as an AND and then also handle outermost ZERO_EXTENDs. I couldn't find a test that benefited from the ANY_EXTEND change, but it's more obvious to write it this way once SIGN_EXTEND and ZERO_EXTEND are handled differently. llvm-svn: 197802
-
Saleem Abdulrasool authored
The .pool directive is an alias for the .ltorg directive used to create a literal pool. Simply treat .pool as if .ltorg was passed. llvm-svn: 197787
-
Tom Stellard authored
v2: Add ftrunc->TRUNC pattern instead of replacing int_AMDGPU_trunc v3: move ftrunc pattern next to TRUNC definition, it's available since R600 Patch By: Jan Vesely Reviewed-by:
Tom Stellard <thomas.stellard@amd.com> Signed-off-by:
Jan Vesely <jan.vesely@rutgers.edu> llvm-svn: 197783
-
Eric Christopher authored
That's what it actually means, and with 16-bit support it's going to be a little more relevant since in a few corner cases we may actually want to distinguish between 16-bit and 32-bit mode (for example the bare 'push' aliases to pushw/pushl etc.) Patch by David Woodhouse llvm-svn: 197768
-
Alp Toker authored
llvm-svn: 197757
-
Kevin Enderby authored
this commit as the only one on the Blamelist so I quickly reverted this. However it was actually Nick's change who has since fixed that issue. Original commit message: Changed the X86 assembler for intel syntax to work with directional labels. The X86 assembler as a separate code to parser the intel assembly syntax in X86AsmParser::ParseIntelOperand(). This did not parse directional labels. And if something like 1f was used as a branch target it would get an "Unexpected token" error. The fix starts in X86AsmParser::ParseIntelExpression() in the case for AsmToken::Integer, it needs to grab the IntVal from the current token then look for a 'b' or 'f' following an Integer. Then it basically needs to do what is done in AsmParser::parsePrimaryExpr() for directional labels. It saves the MCExpr it creates in the IntelExprStateMachine in the Sym field. When it returns to X86AsmParser::ParseIntelOperand() it looks for a non-zero Sym field in the IntelExprStateMachine and if set it creates a memory operand not an immediate operand it would normally do for the Integer. rdar://14961158 llvm-svn: 197744
-
- Dec 19, 2013
-
-
David Peixotto authored
We dump any non-empty assembler constant pools after a successful parse of an assembly file that uses the ldr pseudo opcode. These per-section constant pools should be output in a deterministic order to ensure that we always generate the same output when printing the output with an AsmStreamer. This patch changes the map data struture used to associate a section with its constant pool to a MapVector to ensure deterministic output. Because this map type does not support deletion, we now check that the constant pool is not empty before dumping its entries and clear the entries after emitting them with the streamer. llvm-svn: 197735
-
Kevin Enderby authored
directional labels. Because it doesn't work for windows :) llvm-svn: 197731
-
Kevin Enderby authored
The X86 assembler has a separate code to parser the intel assembly syntax in X86AsmParser::ParseIntelOperand(). This did not parse directional labels. And if something like 1f was used as a branch target it would get an "Unexpected token" error. The fix starts in X86AsmParser::ParseIntelExpression() in the case for AsmToken::Integer, it needs to grab the IntVal from the current token then look for a 'b' or 'f' following the Integer. Then it basically needs to do what is done in AsmParser::parsePrimaryExpr() for directional labels. It saves the MCExpr it creates in the IntelExprStateMachine in the Sym field. When it returns to X86AsmParser::ParseIntelOperand() it looks for a non-zero Sym field in the IntelExprStateMachine and if set it creates a memory operand not an immediate operand it would normally do for the Integer. rdar://14961158 llvm-svn: 197728
-
Quentin Colombet authored
The condition in selects is supposed to be i1. Make sure we are just reading the less significant bit of the 8 bits width value to match this constraint. <rdar://problem/15651765> llvm-svn: 197712
-
David Peixotto authored
This directive will write out the assembler-maintained constant pool for the current section. These constant pools are created to support the ldr-pseudo instruction (e.g. ldr r0, =val). The directive can be used by the programmer to place the constant pool in a location that can be reached by a pc-relative offset in the ldr instruction. llvm-svn: 197711
-
David Peixotto authored
The ldr-pseudo opcode is a convenience for loading 32-bit constants. It is converted into a pc-relative load from a constant pool. For example, ldr r0, =0x10001 ldr r1, =bar will generate this output in the final assembly ldr r0, .Ltmp0 ldr r1, .Ltmp1 ... .Ltmp0: .long 0x10001 .Ltmp1: .long bar Sketch of the LDR pseudo implementation: Keep a map from Section => ConstantPool When parsing ldr r0, =val parse val as an MCExpr get ConstantPool for current Section Label = CreateTempSymbol() remember val in ConstantPool at next free slot add operand to ldr that is MCSymbolRef of Label On finishParse() callback Write out all non-empty constant pools for each Entry in ConstantPool Emit Entry.Label Emit Entry.Value Possible improvements to be added in a later patch: 1. Does not convert load of small constants to mov (e.g. ldr r0, =0x1 => mov r0, 0x1) 2. Does reuse constant pool entries for same constant The implementation was tested for ARM, Thumb1, and Thumb2 targets on linux and darwin. llvm-svn: 197708
-
Rafael Espindola authored
llvm-svn: 197699
-