Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: Hi Jakob, Thanks for the responses.> As you have noticed, the x86 backend only supports stack frames up to 2GB.That's unfortunate. :(> Fixing that would require the x86 backend to use the register > scavenger during prolog epilog insertion like the ARM backend does.Makes sense.> That particular code was very difficult to get right, and no one has > thought it was worth the trouble to get it working for x86.I wouldn't imagine so, since these kinds of large stack objects are rather rare in the C world. They are somewhat more common in the Fortran world. :)> Your life will be a whole lot easier if you just use malloc().Perhaps. This is customer-written code and they will (probably) not be willing to change it. We could replace the allocas with malloc/free under the hood but we haven't needed to do that on past platforms. It's certainly a mildly large change in our compiler in the sense of how resources get allocated. It is certainly doable but for various reasons may be undesirable. Do you have a feel for the complexity involved with the ARM code? What were the troublesome parts and corner cases, etc.? -Dave
On Sep 26, 2011, at 2:46 PM, David A. Greene wrote:>> Fixing that would require the x86 backend to use the register >> scavenger during prolog epilog insertion like the ARM backend does. > > Makes sense. > >> That particular code was very difficult to get right, and no one has >> thought it was worth the trouble to get it working for x86. > > I wouldn't imagine so, since these kinds of large stack objects are > rather rare in the C world. They are somewhat more common in the > Fortran world. :) > >> Your life will be a whole lot easier if you just use malloc(). > > Perhaps. This is customer-written code and they will (probably) not be > willing to change it. We could replace the allocas with malloc/free > under the hood but we haven't needed to do that on past platforms. It's > certainly a mildly large change in our compiler in the sense of how > resources get allocated. It is certainly doable but for various reasons > may be undesirable. > > Do you have a feel for the complexity involved with the ARM code? What > were the troublesome parts and corner cases, etc.?The register scavenger depends on correct kill flags after register allocation. It will assert if it detects something hinky. Adding scavenger support to the x86 PEI is fairly simple. Fixing the many scavenger assertions that follow is not. The fundamental problem is that currently nothing in the x86 target depends on correct liveness after register allocation. Since many post-RA passes modify the code, there is a good chance they will update liveness incorrectly, or not at all in some cases. Your patches to clean this up will be welcome, but please make x86's using the register scavenger enabled by a command line flag. The majority of x86 users don't want to pay the (small) compile time cost and risk of assertions. The machine code verifier checks for the same things as the scavenger, so it should be a help to you. /jakob
> The fundamental problem is that currently nothing in the x86 target depends on correct liveness after register allocation. Since many post-RA passes modify the code, there is a good chance they will update liveness incorrectly, or not at all in some cases.I must note that there are not so many post-RA passes on x86 (comparable to ARM), so things might be a bit easier.> Your patches to clean this up will be welcome, but please make x86's using the register scavenger enabled by a command line flag. The majority of x86 users don't want to pay the (small) compile time cost and risk of assertions.I did this once ~1.5 years ago - it was more or less fine, I believe I saw 4-5 assertions during the whole llvm-gcc bootstrap. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
Hi,>> As you have noticed, the x86 backend only supports stack frames up to 2GB. > > That's unfortunate. :(yes, see PR10488. Ciao, Duncan.
Hi Jakob,> The fundamental problem is that currently nothing in the x86 target depends on correct liveness after register allocation. Since many post-RA passes modify the code, there is a good chance they will update liveness incorrectly, or not at all in some cases. > > Your patches to clean this up will be welcome, but please make x86's using the register scavenger enabled by a command line flag. The majority of x86 users don't want to pay the (small) compile time cost and risk of assertions.wouldn't adding a command line flag just make this feature less tested and more unreliable? It hardly seems worth adding it if it is so unreliable that it typically has to be turned off. Ciao, Duncan.