The CF stack can be corrupted if you use CF_ALU_PUSH_BEFORE,
CF_ALU_ELSE_AFTER, CF_ALU_BREAK, or CF_ALU_CONTINUE when the number of
sub-entries on the stack is greater than or equal to the stack entry
size and sub-entries modulo 4 is either 0 or 3 (on cedar the bug is
present when number of sub-entries module 8 is either 7 or 0)
We choose to be conservative and always apply the work-around when the
number of sub-enries is greater than or equal to the stack entry size,
so that we can safely over-allocate the stack when we are unsure of the
stack allocation rules.
reviewed-by: Vincent Lejeune <vljn at ovi.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199842 91177308-0d34-0410-b5e6-96231b3b80d8
+==============================================================================+
| How to organize the lit tests |
+==============================================================================+
- If you write a test for matching a single DAG opcode or intrinsic, it should
go in a file called {opcode_name,intrinsic_name}.ll (e.g. fadd.ll)
- If you write a test that matches several DAG opcodes and checks for a single
ISA instruction, then that test should go in a file called {ISA_name}.ll (e.g.
bfi_int.ll
- For all other tests, use your best judgement for organizing tests and naming
the files.
+==============================================================================+
| Naming conventions |
+==============================================================================+
- Use dash '-' and not underscore '_' to separate words in file names, unless
the file is named after a DAG opcode or ISA instruction that has an
underscore '_' in its name.
efa1355495