[REGRESSION] UNREACHABLE executed at lib/CodeGen/RegAllocFast.cpp:361!

[compnerd]

Bugzilla Link	26485
Resolution	FIXED
Resolved on	Feb 19, 2016 18:32
Version	3.8
OS	All
Blocks	#26433
Attachments	reduced.c
CC	@zmodem,@qcolombet

Extended Description

This is a regression lowering TLS access in C on Darwin, currently on 3.8 and 3.9 (master). The attached lit-style test case reproduces the fast reg alloc failure. Note that this only occurs at -O0 as the problem is only exhibited for the fast register allocator.

[qcolombet]

I’ll have a look.
Thanks for the report!

[qcolombet]

The bug is actually pretty obvious.
I am surprised this did not crash before!

Basically, we were not tracking properly the definitions of the physical register on calls and because of that, we may reuse one of this physical register for a virtual register before reaching the use of that physical register.
In that case:

CALL32m %EAX, 1, %noreg, 0, %noreg, <regmask %BH %BL %BP %BPL %BX %DI %DIL %EBP %EBX %EDI %ESI %SI %SIL>, %ESP<imp-use>, %EAX<imp-def> ; <— We were not recording that EAX was defined here (and not dead).
%vreg0<def> = MOV32rm %noreg, 1, %noreg, <ga:@c>[TF=18], %noreg; mem:LD4[GOT] GR32:%vreg0 ; <— As a result, we were using EAX here.
ADJCALLSTACKUP32 0, 0, %ESP<imp-def,dead>, %EFLAGS<imp-def,dead>, %ESP<imp-use>
%vreg1<def> = COPY %EAX; GR32:%vreg1 ; <— Regalloc was complaining that EAX is not defined and was reused.

I have a fix. I am polishing the test case and I’ll commit shortly.

Note: The reason why this did not bit us earlier is because the copy that used the return value is usually right after the call. In that case, this is one instruction farther.

[qcolombet]

Committed revision 261384.