RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-21 20:12:56 +02:00
Code Issues Projects Releases Wiki Activity
b94b28812d
llvm-mirror/test/MC/X86/intel-syntax-directional-label.s

18 lines
317 B
ArmAsm
Raw Normal View History

Un-revert: the buildbot failure in LLVM on lld-x86_64-win7 had me with 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
2013-12-20 00:16:14 +01:00
// RUN: llvm-mc -triple x86_64-apple-darwin -x86-asm-syntax=intel %s | FileCheck %s
// rdar://14961158
.text
.align 16
.globl FUNCTION_NAME
.private_extern FUNCTION_NAME
FUNCTION_NAME:
.intel_syntax
cmp rdi, 1
jge 1f
Use printable names to implement directional labels. This changes the implementation of local directional labels to use a dedicated map. With that it can then just use CreateTempSymbol, which is what the rest of MC uses. CreateTempSymbol doesn't do a great job at making sure the names are unique (or being efficient when the names are not needed), but that should probably be fixed in a followup patch. This fixes pr18928. llvm-svn: 203826
2014-03-13 19:09:26 +01:00
// CHECK: jge Ltmp0
Un-revert: the buildbot failure in LLVM on lld-x86_64-win7 had me with 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
2013-12-20 00:16:14 +01:00
add rdi, 2
Use printable names to implement directional labels. This changes the implementation of local directional labels to use a dedicated map. With that it can then just use CreateTempSymbol, which is what the rest of MC uses. CreateTempSymbol doesn't do a great job at making sure the names are unique (or being efficient when the names are not needed), but that should probably be fixed in a followup patch. This fixes pr18928. llvm-svn: 203826
2014-03-13 19:09:26 +01:00
// CHECK: addq $2, %rdi
Un-revert: the buildbot failure in LLVM on lld-x86_64-win7 had me with 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
2013-12-20 00:16:14 +01:00
1:
Use printable names to implement directional labels. This changes the implementation of local directional labels to use a dedicated map. With that it can then just use CreateTempSymbol, which is what the rest of MC uses. CreateTempSymbol doesn't do a great job at making sure the names are unique (or being efficient when the names are not needed), but that should probably be fixed in a followup patch. This fixes pr18928. llvm-svn: 203826
2014-03-13 19:09:26 +01:00
// CHECK: Ltmp0:
Un-revert: the buildbot failure in LLVM on lld-x86_64-win7 had me with 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
2013-12-20 00:16:14 +01:00
add rdi, 1
ret
Reference in New Issue Copy Permalink