LSP instructions still generated when MPC5643L does not support LSP APU

[bcmer]

Hello, 

I'm seeing LSP instructions in my disassembly such as "zstdd", "zldd", "zvaddhss", but the MPC5643L does not support LSP, it only supports SPE. I have tried using the "-mno-lsp" flag and double checked all the include headers to make sure they are for the MPC5643L, but the LSP instructions are still generated. I've ran the debugger and it stops at "se_illegal" instruction. 

C code: 

(void) memset(var, 0, sizeof(minMax_S));

// where var is a pointer to a structure that contains float min and float max. 

Disassembly: 

(void) memset(var, 0, sizeof(minMax_S));
3a2f4: 10 c6 32 16 zvaddhss r6,r6,r6
3a2f8: 48 03 se_li r3,0
3a2fa: 70 e8 e0 00 e_lis r7,16384
3a2fe: 10 c1 13 21 zstdd r6,16(r1)
3a302: 10 c1 0b 21 zstdd r6,8(r1)
3a306: 01 34 se_mr r4,r3
3a308: 1c e7 32 8c e_add16i r7,r7,12940

Tools:

-powerpc-eabivle-4.9.4

-S32 v2.1 & v2017.R1

Thanks

update1:

If I use the -mlsp flag, this is the following error I get, which matches the location of where the LSP instructions are generated without the -mlsp flag: 

X.c:3921:1: error: insn does not satisfy its constraints:

}

^

(insn/f 291 290 292 2 (set (mem/c:V2SI (plus:SI (reg/f:SI 1 %r1)

(const_int 24 [0x18])) [117 S8 A8])

(reg:V2SI 31 %r31)) X.c:3911 2475 {*movv2si_internal}

(expr_list:REG_DEAD (reg:V2SI 31 %r31)

(nil)))

X.c:3921:1: internal compiler error: in copyprop_hardreg_forward_1, at regcprop.c:775

Please submit a full bug report,

with preprocessed source if appropriate.

See <http://gcc.gnu.org/bugs.html> for instructions.

update2: 

If I use -fno-builtin-memset, the LSP instructions are not generated anymore. However, there are still other LSP instruction scattered in the disassembly for code that is not using memset. 

[ra8797 · Accepted solution]

Hi,

The LSP is only supported at assembler and builtins (sort of a inlined assembler). So, the compiler by itself is not capable of generating those instructions.

Thus, the only way to get those instructions in your final code is if you insert then directly through the application (with use of builtins or other form of assembler inlining)

Now, because the assembler supports LSP, there are flags to disassemble those opcodes into mnemonics. Also, most of LSP opcodes maps into SPE opcodes. So, if proper objdump is not used, the disassembler will translate those opcodes to LSP mnemonics when in fact those are SPE mnemonics. (I think the flag is -M spe, but please check the output of objdump -h)

The compiler option -mlsp, is just to enable the LSP builtins, also passes it to the assembler. It has no other effect.

If you still have reason to believe there are LSP instructions in your code, please compile application with -S. That generates assembler (.S) instead of object code (.o). If the assembler (.S file) shows LSP instruction, that is your culprit.

The se_illegal, is an actual instruction, whose opcode is 0x0000. If the CPU tries to execute some LSP instruction, a trap will be generated at that address and debugger will show you the "bad" instruction. It will not be an se_illegal for sure. If you see se_illegal at debugger is likely the CPU jumped to some random place that, by chance, was filled with zeroes. 

I have also seen a case were there was a problem in the customer linker script. The next piece of code were being forced to be world aligned. That created a gap between 2 normal VLE instructions. That gap is filled with zeroes by the linker, and when executed it shows as se_illegal at gdb.

The ICE (internal compiler error) you got is on a SPE 64 bit store instruction. Please re-compile your code with option -save-temps. This will create a file with extension .i

Send this file to us, together with the command line flags you used to compile (Optimization flags) when we reproduce it here, we will analyse it.

Edmar