The btree-based stack allocator thinks that iTemp3 is declared in a different basic block from iTemp6, and they thus cannot overlap.
There seem to be a lot of blocks around for such s short function; I guess they came from inlining somehow.
Philipp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At dumpraw1 iTemp3 and iTemp6 do not yet overlap, but they already do at dumpcse. Looks like the information about the basic blocks does not get updated correctly in cse.
Philipp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe someone more familiar with inline and cse should have a look. I'm not sure if the information on blocks should be handled differently in inlining or in cse.
Philipp
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fixed in [r9833], I think. The block numbers in the AST and variable declarations now look okay to me. The main problem seems to have been that the compiler generated temporary used to hold the inlined function return value had a block number from inside the inlined function even though it would need to be used outside the function as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is a test case (obtained by using the LLVM+SDCC toolchain on the swap regression test and simplifying the result).
Philipp
In the generated asm, both iTemp3 and iTemp6 are at the same stack location.
Philipp
Last edit: Philipp Klaus Krause 2016-11-17
After looking at this a bit further,Inoticed that the problem only happens when using the btree-based stack allocator.
Philipp
The btree-based stack allocator thinks that iTemp3 is declared in a different basic block from iTemp6, and they thus cannot overlap.
There seem to be a lot of blocks around for such s short function; I guess they came from inlining somehow.
Philipp
At dumpraw1 iTemp3 and iTemp6 do not yet overlap, but they already do at dumpcse. Looks like the information about the basic blocks does not get updated correctly in cse.
Philipp
Maybe someone more familiar with inline and cse should have a look. I'm not sure if the information on blocks should be handled differently in inlining or in cse.
Philipp
Fixed in [r9833], I think. The block numbers in the AST and variable declarations now look okay to me. The main problem seems to have been that the compiler generated temporary used to hold the inlined function return value had a block number from inside the inlined function even though it would need to be used outside the function as well.