------- Comment #5 from vmakarov at redhat dot com 2010-03-22 22:16 ------- (In reply to comment #0) > > In the enclosed test case, it generates the following spills for the options: > -O3 -ffast-math -mcpu=power7 -mvsx -maltivec: 117 stfs, 139 lfs > -O3 -ffast-math -mcpu=power5 -maltivec: 80 stfs, 100 lfs > -O3 -ffast-math -mcpu=power5: 80 stfs, 100 lfs
Hi, Mike. I think the comparison should be done with the same -mcpu because there is 1st insn scheduling which increases register pressure differently for different architectures. But that is not so important. I see a lot of spills during assigning because memory is more profitable. Graph coloring pushes them on the stack suggesting that they get registers (and that is not happened during the assignment). On one my branch, I got -O3 -ffast-math -mcpu=power7 -mno-vsx -maltivec: 248 of stfs and lfs -O3 -ffast-math -mcpu=power7 -mvsx -maltivec: 331 of stfs and lfs -O3 -ffast-math -mcpu=power7 -mvsx -maltivec -fsched-pressure: 310 -O3 -ffast-math -mcpu=power7 -mvsx -maltivec -fsched-pressure -fexper: 179 Where -fexper switches on a new graph coloring code without cover classes which I am working on. So I think that this new code and register pressure sensitive insn scheduling will help. Still I'll investigate a bit more why there are a lot of unexpected spills during assignment with -mvsx for the current code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43413
