------- Additional Comments From amacleod at redhat dot com 2005-02-03 16:05 ------- (In reply to comment #26) > > Are we looking to do this at -O2 as well? I guess thats a key question. > > at just -Os, it might very well be sufficient. > > As stevenb noted today in IRC, the code reduction substantially comes from > less > spilling code being emitted, which also means that the generated code *will* > run faster. I guess it's better to have it at -O2 too (until the register > allocator gets fixed, but hey...)
You missed my point. Sure, in the cases where we end up spilling less, its likely to run faster. But we are going to miss combine opportunites in other cases where we wouldnt have spilled in the first place. If we are going to do this at >=-O2, we're probably better off actually looking at how many live ranges we are introducing to solve the issue. If the big expression doesnt introduce too many live ranges, we might as well allow TER to continue and give the expanders a better view. Thats why TER exists in the first place. In any case, its all heuristical, so there will always be cases it doesnt work right for. If we measure SPEC or something else and the simple rootvar approach works fine, then go with it. If there are issues, then we can visit something a bit different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549
