maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/XCore/align.ll

16 lines
226 B
LLVM
Raw Normal View History

[XCore] Prefer to word align functions. The behaviour of the XCore's instruction buffer means that the performance of the same code sequence can differ depending on whether it starts at a 4 byte aligned address or not. Since we don't model the instruction buffer in the backend we have no way of knowing for sure if it is beneficial to word align a specific function. However, in the absence of precise modelling, it is better on balance to word align functions because: * It makes a fetch-nop while executing the prologue slightly less likely. * If we don't word align functions then a small perturbation in one function can have a dramatic knock on effect. If the size of the function changes it might change the alignment and therefore the performance of all the functions that happen to follow it in the binary. This butterfly effect makes it harder to reason about and measure the performance of code. llvm-svn: 202163
2014-02-26 00:37:15 +08:00
; RUN: llc < %s -march=xcore | FileCheck %s
[MC] Use .p2align instead of .align For historic reasons, the behavior of .align differs between targets. Fortunately, there are alternatives, .p2align and .balign, which make the interpretation of the parameter explicit, and which behave consistently across targets. This patch teaches MC to use .p2align instead of .align, so that people reading code for multiple architectures don't have to remember which way each platform does its .align directive. Differential Revision: http://reviews.llvm.org/D16549 llvm-svn: 258750
2016-01-26 08:03:25 +08:00
; CHECK: .p2align 2
[XCore] Prefer to word align functions. The behaviour of the XCore's instruction buffer means that the performance of the same code sequence can differ depending on whether it starts at a 4 byte aligned address or not. Since we don't model the instruction buffer in the backend we have no way of knowing for sure if it is beneficial to word align a specific function. However, in the absence of precise modelling, it is better on balance to word align functions because: * It makes a fetch-nop while executing the prologue slightly less likely. * If we don't word align functions then a small perturbation in one function can have a dramatic knock on effect. If the size of the function changes it might change the alignment and therefore the performance of all the functions that happen to follow it in the binary. This butterfly effect makes it harder to reason about and measure the performance of code. llvm-svn: 202163
2014-02-26 00:37:15 +08:00
; CHECK-LABEL: f:
define void @f() nounwind {
entry:
ret void
}
[MC] Use .p2align instead of .align For historic reasons, the behavior of .align differs between targets. Fortunately, there are alternatives, .p2align and .balign, which make the interpretation of the parameter explicit, and which behave consistently across targets. This patch teaches MC to use .p2align instead of .align, so that people reading code for multiple architectures don't have to remember which way each platform does its .align directive. Differential Revision: http://reviews.llvm.org/D16549 llvm-svn: 258750
2016-01-26 08:03:25 +08:00
; CHECK: .p2align 1
[XCore] Prefer to word align functions. The behaviour of the XCore's instruction buffer means that the performance of the same code sequence can differ depending on whether it starts at a 4 byte aligned address or not. Since we don't model the instruction buffer in the backend we have no way of knowing for sure if it is beneficial to word align a specific function. However, in the absence of precise modelling, it is better on balance to word align functions because: * It makes a fetch-nop while executing the prologue slightly less likely. * If we don't word align functions then a small perturbation in one function can have a dramatic knock on effect. If the size of the function changes it might change the alignment and therefore the performance of all the functions that happen to follow it in the binary. This butterfly effect makes it harder to reason about and measure the performance of code. llvm-svn: 202163
2014-02-26 00:37:15 +08:00
; CHECK-LABEL: g:
define void @g() nounwind optsize {
entry:
ret void
}