http://llvm.org https://git.amat.us/llvm/atom/test/CodeGen/Generic?h=release_26 2009-07-24T00:30:09Z 2009-07-24T00:30:09Z Dan Gohman gohman@apple.com 2009-07-24T00:30:09Z urn:sha1:d2cb3d2c32b8f53bf94d56fbdd48503ace28df4b git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76920 91177308-0d34-0410-b5e6-96231b3b80d8 2009-07-12T21:30:06Z Chris Lattner sabre@nondot.org 2009-07-12T21:30:06Z urn:sha1:4cef7db13f9ad73ca1d1caaa08358430597ad557 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75433 91177308-0d34-0410-b5e6-96231b3b80d8 2009-06-04T22:49:04Z Dan Gohman gohman@apple.com 2009-06-04T22:49:04Z urn:sha1:ae3a0be92e33bc716722aa600983fc1535acb122 integer and floating-point opcodes, introducing FAdd, FSub, and FMul. For now, the AsmParser, BitcodeReader, and IRBuilder all preserve backwards compatability, and the Core LLVM APIs preserve backwards compatibility for IR producers. Most front-ends won't need to change immediately. This implements the first step of the plan outlined here: http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72897 91177308-0d34-0410-b5e6-96231b3b80d8 2009-06-03T21:42:06Z Eli Friedman eli.friedman@gmail.com 2009-06-03T21:42:06Z urn:sha1:a8ba2c25e9ea7b0d213b485debe5d044efde66a4 DominatorTreeBase::Split. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72810 91177308-0d34-0410-b5e6-96231b3b80d8 2009-05-22T20:36:31Z Duncan Sands baldrick@free.fr 2009-05-22T20:36:31Z urn:sha1:b0f1e1780c736c62fb99e5824825d2a60a53b53b code in preparation for code generation. The main thing it does is handle the case when eh.exception calls (and, in a future patch, eh.selector calls) are far away from landing pads. Right now in practice you only find eh.exception calls close to landing pads: either in a landing pad (the common case) or in a landing pad successor, due to loop passes shifting them about. However future exception handling improvements will result in calls far from landing pads: (1) Inlining of rewinds. Consider the following case: In function @f: ... invoke @g to label %normal unwind label %unwinds ... unwinds: %ex = call i8* @llvm.eh.exception() ... In function @g: ... invoke @something to label %continue unwind label %handler ... handler: %ex = call i8* @llvm.eh.exception() ... perform cleanups ... "rethrow exception" Now inline @g into @f. Currently this is turned into: In function @f: ... invoke @something to label %continue unwind label %handler ... handler: %ex = call i8* @llvm.eh.exception() ... perform cleanups ... invoke "rethrow exception" to label %normal unwind label %unwinds unwinds: %ex = call i8* @llvm.eh.exception() ... However we would like to simplify invoke of "rethrow exception" into a branch to the %unwinds label. Then %unwinds is no longer a landing pad, and the eh.exception call there is then far away from any landing pads. (2) Using the unwind instruction for cleanups. It would be nice to have codegen handle the following case: invoke @something to label %continue unwind label %run_cleanups ... handler: ... perform cleanups ... unwind This requires turning "unwind" into a library call, which necessarily takes a pointer to the exception as an argument (this patch also does this unwind lowering). But that means you are using eh.exception again far from a landing pad. (3) Bugpoint simplifications. When bugpoint is simplifying exception handling code it often generates eh.exception calls far from a landing pad, which then causes codegen to assert. Bugpoint then latches on to this assertion and loses sight of the original problem. Note that it is currently rare for this pass to actually do anything. And in fact it normally shouldn't do anything at all given the code coming out of llvm-gcc! But it does fire a few times in the testsuite. As far as I can see this is almost always due to the LoopStrengthReduce codegen pass introducing pointless loop preheader blocks which are landing pads and only contain a branch to another block. This other block contains an eh.exception call. So probably by tweaking LoopStrengthReduce a bit this can be avoided. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72276 91177308-0d34-0410-b5e6-96231b3b80d8 2009-05-16T00:34:42Z Jakob Stoklund Olesen stoklund@2pi.dk 2009-05-16T00:34:42Z urn:sha1:f8eac02fc1f544f9b18ffdcda68b3a9849448429 When a test fails with more than a pipeful of output on stdout AND stderr, one of the DejaGnu programs blocks. The problem can be avoided by redirecting stdout to a file. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71919 91177308-0d34-0410-b5e6-96231b3b80d8 2009-04-29T03:45:07Z Chris Lattner sabre@nondot.org 2009-04-29T03:45:07Z urn:sha1:672452d5a0dace689d7f9df9837c03afe3a74281 anything larger than 64-bits, avoiding a crash. This should really be fixed to use APInts, though type legalization happens to help us out and we get good code on the attached testcase at least. This fixes rdar://6836460 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70360 91177308-0d34-0410-b5e6-96231b3b80d8 2009-04-29T00:15:41Z Bill Wendling isanbard@gmail.com 2009-04-29T00:15:41Z urn:sha1:be8cc2a3dedeb7685f07e68cdc4b9502eb97eb2b Massive check in. This changes the "-fast" flag to "-O#" in llc. If you want to use the old behavior, the flag is -O0. This change allows for finer-grained control over which optimizations are run at different -O levels. Most of this work was pretty mechanical. The majority of the fixes came from verifying that a "fast" variable wasn't used anymore. The JIT still uses a "Fast" flag. I'll change the JIT with a follow-up patch. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70343 91177308-0d34-0410-b5e6-96231b3b80d8 2009-04-28T01:04:53Z Bill Wendling isanbard@gmail.com 2009-04-28T01:04:53Z urn:sha1:c69d56f1154342a57c9bdd4c17a10333e3520127 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70275 91177308-0d34-0410-b5e6-96231b3b80d8 2009-04-28T00:21:31Z Bill Wendling isanbard@gmail.com 2009-04-28T00:21:31Z urn:sha1:2e9d5f912a9841d3685ba0241abe1131943fed29 use the old behavior, the flag is -O0. This change allows for finer-grained control over which optimizations are run at different -O levels. Most of this work was pretty mechanical. The majority of the fixes came from verifying that a "fast" variable wasn't used anymore. The JIT still uses a "Fast" flag. I'm not 100% sure if it's necessary to change it there... git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70270 91177308-0d34-0410-b5e6-96231b3b80d8