#2326 LUT retrieval index wrong

[frank26080115]

I am working with a STM8S903 chip and SDCC version 3.4.0 #8981

I have a problem with a look-up table implementation, the table looks like key-value-value, like this http://pastebin.com/A8iR2ACN (expected and actual output is done using LED, shown in code comments)

The array index isn't calculated properly and the wrong value is fetched from the LUT

I have pasted the assembly http://pastebin.com/PtwUP8ev

Compile flags are

CFLAGS = -c -mstm8 -DSTM8S903 -I. -I$(STDPERIPH_DIR)/inc --opt-code-size --std-sdcc99 --funsigned-char
LDFLAGS = -mstm8 stm8.lib $(PERIPH_LIB) -L $(STDPERIPH_DIR)/src

Attached ZIP file also contains all files necessary

the sample code does seem to reproduce the problem, I have a much bigger project that uses a similar function that exhibits the problem on STM8S but not on AVR

[Philipp Klaus Krause]

This affects all ports. --nogcse is a workaround.

Philipp

[Erik Petrich]

Partially fixed by revision [r9146] . Strength reduction optimization removed the need for i's register equivalent iTemp, but for some reason dead code elimination is not removing the initial assignment. Since i is never used, its iTemp was not assigned any register or a spill location allocated; however, the code generated assumed it was spilled because there was a spill location assigned (the original symbol i). Because the spill location was not actually allocated, the assignment corrupted another iTemp spilled to the stack that was part of the LUT index. Revision 9146 prevents the use of spill locations when the register allocator has not formally spilled the iTemp, thus preventing this sort of corruption.

Still pending is why the assignment remained instead of being removed by dead code elimination.

[Philipp Klaus Krause]

@epetrich, can you check if that undead assigment is still around in current SDCC? If not, this ticket could be closed?