mirror of
https://github.com/Cisco-Talos/clamav.git
synced 2025-11-09 20:41:03 +00:00
9da1704025
This brings in some memory leak fixes for LLVMCOntext.
Squashed commit of the following:
commit 4cfaf41d499ce05b11ecb62746c3e86b04440f62
Author: Bill Wendling <isanbard@gmail.com>
Date: Mon Aug 31 18:26:48 2009 +0000
Output a hex value, because all of the others are hex.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80601 91177308-0d34-0410-b5e6-96231b3b80d8
commit 7829e5a6558bb97589d47d61da3142f7ebbdaeac
Author: Dale Johannesen <dalej@apple.com>
Date: Mon Aug 31 18:05:23 2009 +0000
Fix some misspellings of XTARGET.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80598 91177308-0d34-0410-b5e6-96231b3b80d8
commit 8364630e4cb67b6f64a704960e73ae44ce3f10ed
Author: Dale Johannesen <dalej@apple.com>
Date: Mon Aug 31 17:49:20 2009 +0000
Mark test as passing on all x86, which it should,
although I don't think anyone cares about this
feature except Darwin. PR 4825.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80596 91177308-0d34-0410-b5e6-96231b3b80d8
commit cf91fb4cb2e15b1fa07dc1282ac59c3659d80015
Author: Chris Lattner <sabre@nondot.org>
Date: Mon Aug 31 17:08:30 2009 +0000
cleanups pointed out by duncan
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80595 91177308-0d34-0410-b5e6-96231b3b80d8
commit 752d366fe7a9d0f68258465ce554cdf40af2918e
Author: Duncan Sands <baldrick@free.fr>
Date: Mon Aug 31 16:45:16 2009 +0000
Revert commit 80428. It completely broke exception
handling on x86-32 linux.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80592 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3c8dfbb88bb125c2b7d1105645937b14dce9bcd3
Author: Edwin Török <edwintorok@gmail.com>
Date: Mon Aug 31 16:14:59 2009 +0000
Free the constants that have no uses in ~LLVMContext.
This fixes leaks from LLVMContext in multithreaded apps.
Since constants are only deleted if they have no uses, it is safe to not delete
a Module on shutdown, as many single-threaded tools do.
Multithreaded apps should however delete the Module before destroying the
Context to ensure that there are no leaks (assuming they use a different context
for each thread).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80590 91177308-0d34-0410-b5e6-96231b3b80d8
commit 6d5f43b77a907a2b42ff405ab16e078c6598c70e
Author: Edwin Török <edwintorok@gmail.com>
Date: Mon Aug 31 16:12:29 2009 +0000
Fix ExplicitSymbols leak.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80589 91177308-0d34-0410-b5e6-96231b3b80d8
commit b759ebc5bc48ee93a9f4b031ec6ed3247028d77c
Author: Benjamin Kramer <benny.kra@googlemail.com>
Date: Mon Aug 31 13:05:24 2009 +0000
Normalize makefile comments and sort cmake file lists.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80584 91177308-0d34-0410-b5e6-96231b3b80d8
commit d79f43204be2893e74872f1062e2a44f023d39e1
Author: Daniel Dunbar <daniel@zuster.org>
Date: Mon Aug 31 08:09:28 2009 +0000
llvm-mc: Pass values to MCStreamer as MCExprs, not MCValues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80578 91177308-0d34-0410-b5e6-96231b3b80d8
commit f4c67959b5ea0bbd3a39085c91c2d3162c6fd973
Author: Daniel Dunbar <daniel@zuster.org>
Date: Mon Aug 31 08:09:09 2009 +0000
llvm-mc: Simplify EmitAssignment ('.set' is identical to '=').
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80577 91177308-0d34-0410-b5e6-96231b3b80d8
commit b6a03e093598d90c10c8d1cab8425e3d107b12cf
Author: Daniel Dunbar <daniel@zuster.org>
Date: Mon Aug 31 08:08:50 2009 +0000
llvm-mc: Remove MCAsmParser::Parse[Paren]RelocatableExpression.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80576 91177308-0d34-0410-b5e6-96231b3b80d8
commit 6e96621a502ddebc12cd4d139756b7a90fd1ca8a
Author: Daniel Dunbar <daniel@zuster.org>
Date: Mon Aug 31 08:08:38 2009 +0000
llvm-mc: Switch MCInst to storing an MCExpr* instead of an MCValue.
Also, use MCInst::print instead of custom code in MCAsmPrinter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80575 91177308-0d34-0410-b5e6-96231b3b80d8
commit 667cfd44ac3394697e60f54f72bfd190436c061a
Author: Daniel Dunbar <daniel@zuster.org>
Date: Mon Aug 31 08:08:17 2009 +0000
llvm-mc: Add MCAsmParser::Parse[Paren]Expression forms which return an MCExpr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80574 91177308-0d34-0410-b5e6-96231b3b80d8
commit 22ad5f80f751da3ba986022d09c49fcc4416048a
Author: Daniel Dunbar <daniel@zuster.org>
Date: Mon Aug 31 08:08:06 2009 +0000
llvm-mc: Make MCSymbolData symbol member const.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80573 91177308-0d34-0410-b5e6-96231b3b80d8
commit 29efe7e0c9d32aaefa2a2924a8ded5fd4c76ff28
Author: Daniel Dunbar <daniel@zuster.org>
Date: Mon Aug 31 08:07:55 2009 +0000
llvm-mc: Add MCContext to MCAssembler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80572 91177308-0d34-0410-b5e6-96231b3b80d8
commit 890ebe2d940760796e088902a2613cdf30b16e76
Author: Daniel Dunbar <daniel@zuster.org>
Date: Mon Aug 31 08:07:44 2009 +0000
llvm-mc: Add MCAsmParser::getContext.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80571 91177308-0d34-0410-b5e6-96231b3b80d8
commit 510c1a5512b7de68dc9b272eaba0e5d6c3ddc8b9
Author: Daniel Dunbar <daniel@zuster.org>
Date: Mon Aug 31 08:07:33 2009 +0000
llvm-mc: Add MCExpr::{dump,print}.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80570 91177308-0d34-0410-b5e6-96231b3b80d8
commit bc4d607b1a5fd13c1f19ef812ebb6fe814831d56
Author: Daniel Dunbar <daniel@zuster.org>
Date: Mon Aug 31 08:07:22 2009 +0000
llvm-mc: Switch MCExpr construction to using static member functions, and taking the MCContext (which now owns all MCExprs).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80569 91177308-0d34-0410-b5e6-96231b3b80d8
commit 6e3b031540ae25a464bfa37cdbd19e2cad301ee7
Author: Daniel Dunbar <daniel@zuster.org>
Date: Mon Aug 31 08:07:08 2009 +0000
llvm-mc: Add some doxyment markers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80568 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3679d2f3156d001053bae8fa5a162852b7700a27
Author: Daniel Dunbar <daniel@zuster.org>
Date: Mon Aug 31 08:06:59 2009 +0000
llvm-mc: Move AsmExpr into MC lib (as MCExpr).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80567 91177308-0d34-0410-b5e6-96231b3b80d8
commit 298ea10f4da28d9be51f8be5af59f88ea86ce7ec
Author: Chris Lattner <sabre@nondot.org>
Date: Mon Aug 31 07:23:46 2009 +0000
Step #1 to giving Callgraph some sane invariants. The problems with callgraph
stem from the fact that we have two types of passes that need to update it:
1. callgraphscc and module passes that are explicitly aware of it
2. Functionpasses (and loop passes etc) that are interlaced with CGSCC passes
by the CGSCC Passmgr.
In the case of #1, we can reasonably expect the passes to update the call
graph just like any analysis. However, functionpasses are not and generally
should not be CG aware. This has caused us no end of problems, so this takes
a new approach. Logically, the CGSCC Pass manager can rescan every function
after it runs a function pass over it to see if the functionpass made any
updates to the IR that affect the callgraph. This allows it to catch new calls
introduced by the functionpass.
In practice, doing this would be slow. This implementation keeps track of
whether or not the current scc is dirtied by a function pass, and, if so,
delays updating the callgraph until it is actually needed again. This was
we avoid extraneous rescans, but we still have good invariants when the
callgraph is needed.
Step #2 of the "give Callgraph some sane invariants" is to change CallGraphNode
to use a CallBackVH for the callsite entry of the CallGraphNode. This way
we can immediately remove entries from the callgraph when a FunctionPass is
active instead of having dangling pointers. The current pass tries to tolerate
these dangling pointers, but it is just an evil hack.
This is related to PR3601/4835/4029. This also reverts r80541, a hack working
around the sad lack of invariants.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80566 91177308-0d34-0410-b5e6-96231b3b80d8
commit 21d79e26df48405ff2fdfde682c4fdf6c646ef8a
Author: Chris Lattner <sabre@nondot.org>
Date: Mon Aug 31 06:57:37 2009 +0000
fix some cases where instcombine would change hte IR but not return true
from runOnFunction
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80562 91177308-0d34-0410-b5e6-96231b3b80d8
commit 223479b6087a6d9a1470c857c459e408ba51df84
Author: Chris Lattner <sabre@nondot.org>
Date: Mon Aug 31 06:01:21 2009 +0000
cleanups, factor some code out to a helper function
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80542 91177308-0d34-0410-b5e6-96231b3b80d8
commit f5313424550268526a14fd910cfb59efb95e0f30
Author: Chris Lattner <sabre@nondot.org>
Date: Mon Aug 31 05:46:59 2009 +0000
fix a crash building SPASS by tolerating a callsite that doesn't exist
in the callgraph, see the big comment at the top of the testcase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80541 91177308-0d34-0410-b5e6-96231b3b80d8
commit 4c76b7e8e15bf7ed6607393535f64a9070b6df8c
Author: Chris Lattner <sabre@nondot.org>
Date: Mon Aug 31 05:34:32 2009 +0000
comment and simplify some code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80540 91177308-0d34-0410-b5e6-96231b3b80d8
commit d441cd63a37ec3589fed1cfba11bbb177dab8fa6
Author: Chris Lattner <sabre@nondot.org>
Date: Mon Aug 31 05:22:48 2009 +0000
add -debug output
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80539 91177308-0d34-0410-b5e6-96231b3b80d8
commit 26b7f945b3a935e44755202ef7be13fdee8c75b5
Author: Chris Lattner <sabre@nondot.org>
Date: Mon Aug 31 05:17:58 2009 +0000
improve -debug output, so that -debug is more likely to print when
instcombine is changing stuff.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80538 91177308-0d34-0410-b5e6-96231b3b80d8
commit adba7ea53650f26a6752f606041ac6d741c1fd4f
Author: Chris Lattner <sabre@nondot.org>
Date: Mon Aug 31 04:36:22 2009 +0000
fix a bug I introduced with my 'instcombine builder' refactoring
changes: SimplifyDemandedBits can't use the builder yet because it
has the wrong insertion point. This fixes a crash building
MultiSource/Benchmarks/PAQ8p
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80537 91177308-0d34-0410-b5e6-96231b3b80d8
commit b74203603b43d08ddef33e9a4c9c03752d86aee6
Author: Chris Lattner <sabre@nondot.org>
Date: Mon Aug 31 04:09:04 2009 +0000
simplify some code by making the SCCNodes set contain Function*'s
instead of CallGraphNode*'s. This also papers over a callgraph
problem where a pass (in this case, MemCpyOpt) introduces a new
function into the module (llvm.memset.i64) but doesn't add it to
the call graph (nor should it, since it is a function pass).
While it might be a good idea for MemCpyOpt to not synthesize
functions in a runOnFunction(), there is no need for FunctionAttrs
to be boneheaded, so fix it there. This fixes an assertion building
176.gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80535 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3e30f91f1c190b8f3ba93de2c8746e0addaf056e
Author: Chris Lattner <sabre@nondot.org>
Date: Mon Aug 31 03:22:35 2009 +0000
only print the override triple if it exists!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80534 91177308-0d34-0410-b5e6-96231b3b80d8
commit fd7079292b43ca5eceae2c585fc2899033a448f7
Author: Chris Lattner <sabre@nondot.org>
Date: Mon Aug 31 03:15:49 2009 +0000
Fix PR4834, a tricky case where the inliner would resolve an
indirect function pointer, inline it, then go to delete the body.
The problem is that the callgraph had other references to the function,
though the inliner had no way to know it, so we got a dangling pointer
and an invalid iterator out of the deal.
The fix to this is pretty simple: stop the inliner from deleting the
function by knowing that there are references to it. Do this by making
CallGraphNodes contain a refcount. This requires moving deletion of
available_externally functions to the module-level cleanup sweep where
it belongs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80533 91177308-0d34-0410-b5e6-96231b3b80d8
commit 7d7776f7adca3f51d05c3bbfbacaf65a5ae5167f
Author: Chris Lattner <sabre@nondot.org>
Date: Mon Aug 31 02:24:20 2009 +0000
use an accessor instead of poking internals of a node.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80532 91177308-0d34-0410-b5e6-96231b3b80d8
commit 7032b5cbb5282c844008e780c7bbdddf8f8cf096
Author: Oscar Fuentes <ofv@wanadoo.es>
Date: Mon Aug 31 01:58:50 2009 +0000
CMake: updated library dependencies.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80531 91177308-0d34-0410-b5e6-96231b3b80d8
commit 54b6adfbb882f2f9b96c241fb87d0128ce840960
Author: Jim Grosbach <grosbach@apple.com>
Date: Mon Aug 31 01:35:03 2009 +0000
PR4747
Shared landing pads run into trouble with SJLJ, as the dispatch table is
mapped to call sites, and merging the pads will throw that off. There needs
to be a one-to-one mapping of landing pad exception table entries to invoke
call points.
Detecting the shared pad during lowering of SJLJ info insn't sufficient, as
the dispatch function may still need separate destinations to properly
handle phi-nodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80530 91177308-0d34-0410-b5e6-96231b3b80d8
commit 86ab47ae9c388e9e046dedd9d9d554268290e450
Author: Chris Lattner <sabre@nondot.org>
Date: Mon Aug 31 00:28:46 2009 +0000
update unit test for previous change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80528 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3dab7152eedc0d822a9499102303eba526026021
Author: Chris Lattner <sabre@nondot.org>
Date: Mon Aug 31 00:19:58 2009 +0000
Fix some nasty callgraph dangling pointer problems in
argpromotion and structretpromote. Basically, when replacing
a function, they used the 'changeFunction' api which changes
the entry in the function map (and steals/reuses the callgraph
node).
This has some interesting effects: first, the problem is that it doesn't
update the "callee" edges in any callees of the function in the call graph.
Second, this covers for a major problem in all the CGSCC pass stuff, which
is that it is completely broken when functions are deleted if they *don't*
reuse a CGN. (there is a cute little fixme about this though :).
This patch changes the protocol that CGSCC passes must obey: now the CGSCC
pass manager copies the SCC and preincrements its iterator to avoid passes
invalidating it. This allows CGSCC passes to mutate the current SCC. However
multiple passes may be run on that SCC, so if passes do this, they are now
required to *update* the SCC to be current when they return.
Other less interesting parts of this patch are that it makes passes update
the CG more directly, eliminates changeFunction, and requires clients of
replaceCallSite to specify the new callee CGN if they are changing it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80527 91177308-0d34-0410-b5e6-96231b3b80d8
commit 637d133ffeaa961837ebc87ee6934be5ef401b8f
Author: Erick Tryzelaar <idadesub@users.sourceforge.net>
Date: Sun Aug 30 23:41:20 2009 +0000
Fix header comment for bindings/ocaml/llvm/Makefile.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80526 91177308-0d34-0410-b5e6-96231b3b80d8
commit ad465d7013a6ec529a34605d51377202af71b418
Author: Erick Tryzelaar <idadesub@users.sourceforge.net>
Date: Sun Aug 30 23:38:06 2009 +0000
Make sure we specify no arguments for context functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80525 91177308-0d34-0410-b5e6-96231b3b80d8
commit ba263e5f1b2320558e3935bbfbdc10c6d581c19d
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 22:24:32 2009 +0000
add a dump() method on callgraph.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80524 91177308-0d34-0410-b5e6-96231b3b80d8
commit 72489759fa9fb63fdfa9f2e363222f0c45bf1340
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 22:14:17 2009 +0000
rename test
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80523 91177308-0d34-0410-b5e6-96231b3b80d8
commit fae478e46e8ba5192eebbe569a627fdb954e587f
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 22:13:26 2009 +0000
merge all sinking tests into one and convert them to filecheck.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80522 91177308-0d34-0410-b5e6-96231b3b80d8
commit a94b6974dd77e6457eba731fc6bf760d150f4207
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 22:08:19 2009 +0000
convert scalar_promote to filecheck style and merge 2003-12-13-VolatilePromote.ll into it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80521 91177308-0d34-0410-b5e6-96231b3b80d8
commit 9e2f641e11c20fa64e5f605e00168ecc7c0207b6
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 21:45:23 2009 +0000
eliminate some uses of prcontext. Any help here would be appreciated :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80520 91177308-0d34-0410-b5e6-96231b3b80d8
commit b5d911fe3ad0daa3bab9f6ddb24931db969fed00
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 21:36:39 2009 +0000
rename test so that name reflects what it is testing for.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80519 91177308-0d34-0410-b5e6-96231b3b80d8
commit 16078ca613ec085b395afbabf5b68b7062e0ac1c
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 21:36:06 2009 +0000
convert to filecheck format.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80518 91177308-0d34-0410-b5e6-96231b3b80d8
commit 0799dd19d3f0c2f1beb1b17ef7842ae5b61043d2
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 21:31:34 2009 +0000
suck a bunch more gep tests into getelementptr.ll and filecheckize them all.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80517 91177308-0d34-0410-b5e6-96231b3b80d8
commit 16d7262e7a2e523c97e2c8bb2b4ab8823cf05772
Author: Daniel Dunbar <daniel@zuster.org>
Date: Sun Aug 30 21:14:05 2009 +0000
Tweak comment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80516 91177308-0d34-0410-b5e6-96231b3b80d8
commit 6a8458c86c784f7955ab7815b4840fc21f27b2d8
Author: Daniel Dunbar <daniel@zuster.org>
Date: Sun Aug 30 21:13:58 2009 +0000
Fix some possible-use-of-uninitialized warnings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80515 91177308-0d34-0410-b5e6-96231b3b80d8
commit 909749e25e3d5442e5b407781d2de92871f81a64
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 21:02:36 2009 +0000
consolodate various GEP tests into getelementptr.ll using filecheck.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80514 91177308-0d34-0410-b5e6-96231b3b80d8
commit ccf7551a0445599b24a0eae667242e67b5f5d298
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 21:02:02 2009 +0000
another huge testcase, this time from 'gs' in llvm-test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80513 91177308-0d34-0410-b5e6-96231b3b80d8
commit 1fa629a0ffe6aa837bda41389c098e236a5b0f0c
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 21:01:14 2009 +0000
remove another poorly-reduced testcase which came from ldecod in llvm-test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80512 91177308-0d34-0410-b5e6-96231b3b80d8
commit 36d9c48134861d576a78c09e001d7773a502ea76
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 21:00:11 2009 +0000
this testcase is 500 lines long and is distilled from bzip2, just
remove it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80511 91177308-0d34-0410-b5e6-96231b3b80d8
commit 586de4da4bffce2aae9110a60a39a3318014674c
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 20:48:15 2009 +0000
convert to filecheck
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80510 91177308-0d34-0410-b5e6-96231b3b80d8
commit 83288fa512830d723318bf99060d3ec4fbf53abc
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 20:38:21 2009 +0000
Fix PR4748: don't fold gep(bitcast(x)) into bitcast(gep) when x
is itself a bitcast. Since we have gep(bitcast(bitcast(y))) in this
case, just wait for the two bitcasts to get zapped. This prevents
instcombine from confusing some aliasing stuff, and allows it to
directly eliminate the load in the testcase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80508 91177308-0d34-0410-b5e6-96231b3b80d8
commit f3a2359906e6939a2552c7c23877592693d757f1
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 20:36:46 2009 +0000
misc cleanup
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80507 91177308-0d34-0410-b5e6-96231b3b80d8
commit 6807a24de176e563843a0c5a21c9358b5eeefc2d
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 20:06:40 2009 +0000
add getPointerAddressSpace() to GEP instruction, use the method
in a few scalar xforms to simplify things.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80506 91177308-0d34-0410-b5e6-96231b3b80d8
commit d6164c20cdaaa27a2cc7b340604b4df3f2b97129
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 20:01:10 2009 +0000
eliminate InsertCastBefore, use the builder instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80505 91177308-0d34-0410-b5e6-96231b3b80d8
commit 78628294ebe9a062fbd7e55edf5240e9b7c53fce
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 19:47:22 2009 +0000
eliminate InsertBitCastBefore, just use the builder instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80504 91177308-0d34-0410-b5e6-96231b3b80d8
commit b77b0464ba62108a07af655f626f5bfe3bd63162
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 19:45:21 2009 +0000
add a "getPointerAddressSpace" helper method to LoadInst and StoreInst.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80503 91177308-0d34-0410-b5e6-96231b3b80d8
commit d33527768525e6447c6fdcf521ffb975165dbc7a
Author: Anton Korobeynikov <asl@math.spbu.ru>
Date: Sun Aug 30 19:06:39 2009 +0000
Add missed pattern
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80502 91177308-0d34-0410-b5e6-96231b3b80d8
commit ad7516ac00ede459691feba7f448a4c3654ea6fc
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 18:50:58 2009 +0000
convert a bunch more calls to InsertNewInstBefore to use
the new Instcombine builder.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80501 91177308-0d34-0410-b5e6-96231b3b80d8
commit 36ec3b4e9828905bdc6bf7ef91ac808ab11e7d45
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 17:53:59 2009 +0000
fix typo
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80500 91177308-0d34-0410-b5e6-96231b3b80d8
commit 8ba22dd113839d66b3f2912aff6bdd27776b1608
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 17:44:10 2009 +0000
hopefully unbreak the build by making this-> explicit for dependent
base class lookup.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80499 91177308-0d34-0410-b5e6-96231b3b80d8
commit 243874430bb02c8f76b7603cbc8f31ebf2749785
Author: Anton Korobeynikov <asl@math.spbu.ru>
Date: Sun Aug 30 17:14:54 2009 +0000
EXTRACT_VECTOR_ELEMENT can have result type different from element type.
Remove the assertion and generalize the code for ARM NEON stuff.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80498 91177308-0d34-0410-b5e6-96231b3b80d8
commit 42cee05a28e87ba96760daaf9699f8355ea53f6e
Author: Edwin Török <edwintorok@gmail.com>
Date: Sun Aug 30 08:24:09 2009 +0000
Add regular expression matching support, based on OpenBSD regexec()/regcomp()
implementation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80493 91177308-0d34-0410-b5e6-96231b3b80d8
commit c769485a593b86360597d913c083292279730695
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 07:44:24 2009 +0000
give instcombine a custom IRBuilder that adds new instructions to the
workslist and is set to insert new instructions before the current one.
Convert a bunch of stuff that used to call InsertNewInstBefore over to
use it, greatly simplifying code and making it more natural.
There is still a lot more to go, but this is a good start.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80492 91177308-0d34-0410-b5e6-96231b3b80d8
commit f0b47f327e20f338c90202ea21001dd9b06f7ef5
Author: Daniel Dunbar <daniel@zuster.org>
Date: Sun Aug 30 07:01:09 2009 +0000
Update test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80490 91177308-0d34-0410-b5e6-96231b3b80d8
commit c5ad98f04a19b2b7d463713a77634471578d1a64
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 06:27:41 2009 +0000
add a new InstCombineWorklist::AddValue method that works even
if the operand is not an instruction.
Simplify most uses of AddOperandsToWorkList to use AddValue and
inline it into the one remaining callsite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80488 91177308-0d34-0410-b5e6-96231b3b80d8
commit 4796b62fccd6f8c414b5a642ebe0f6dbbabd5b61
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 06:22:51 2009 +0000
move AddUsersToWorkList to the worklist processing class, make the
argument stronger typed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80487 91177308-0d34-0410-b5e6-96231b3b80d8
commit 059cfc7570d47711c1b53c909ab0f9c347cb23c3
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 06:20:05 2009 +0000
rename AddUsesToWorkList -> AddOperandsToWorkList. The
former looks too much like AddUsersToWorkList and keeps
confusing me.
Remove AddSoonDeadInstToWorklist and change its two callers
to do the same thing in a simpler way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80486 91177308-0d34-0410-b5e6-96231b3b80d8
commit a8d310b5231890e926000c6939540b93fe094b61
Author: Daniel Dunbar <daniel@zuster.org>
Date: Sun Aug 30 06:17:49 2009 +0000
llvm-mc/X86: Encode constant MCValue's correctly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80485 91177308-0d34-0410-b5e6-96231b3b80d8
commit b03d1179e934cb99e30190835fea1e7f4a59ecad
Author: Daniel Dunbar <daniel@zuster.org>
Date: Sun Aug 30 06:17:16 2009 +0000
llvm-mc: MCStreamer cleanups. - Remove EmitLocalSymbol, this is unsupported for now.
- Switch Emit{CommonSymbol,Zerofill} to take alignment in bytes (for consistency).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80484 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3183fb6b613c15627c33a8257cbbfe10dbf0bb7f
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 06:13:40 2009 +0000
inline the trivial AddToWorkList/RemoveFromWorkList methods
into their callers. simplify ReplaceInstUsesWith. Make
EraseInstFromFunction only add operands to the worklist if
there aren't too many of them (this was a scalability win
for crazy programs that was only infrequently enforced).
Switch more code to using EraseInstFromFunction instead of
duplicating it inline. Change some fcmp/icmp optimizations
to modify fcmp/icmp in place instead of creating a new one
and deleting the old one just to change the predicate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80483 91177308-0d34-0410-b5e6-96231b3b80d8
commit bf09d6330ea039406e250493d7e45d001f81734d
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 05:56:44 2009 +0000
fix a bug I introduced in r80478 found by the build bot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80482 91177308-0d34-0410-b5e6-96231b3b80d8
commit 5119c70d1620b79288c50ca2ad6a3ea4f11a3f35
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 05:55:36 2009 +0000
refactor instcombine's worklist processing stuff out to its own class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80481 91177308-0d34-0410-b5e6-96231b3b80d8
commit 1dde4eb8a0aef903bfd53d8dabfc61a560e1b327
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 05:55:04 2009 +0000
make DenseMap::clear() early exit if there is nothing to do.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80480 91177308-0d34-0410-b5e6-96231b3b80d8
commit 69af0ff152a949c41ea8ff4550c74627306262f7
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 05:42:59 2009 +0000
some minor cleanups to IRBuilder, factor the insertion
hook out of the main IRBuilder class to allow clients to
override it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80479 91177308-0d34-0410-b5e6-96231b3b80d8
commit 1c641fc37fc42d878883b0325810a5c8c02a436c
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 05:30:55 2009 +0000
more cleanups: remove some redundant code, and simplify some
other places.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80478 91177308-0d34-0410-b5e6-96231b3b80d8
commit c2c8a0ac3f529c9e536862b213e18f67de05f422
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 05:08:50 2009 +0000
eliminate the temporary SrcGEPOperands smallvector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80477 91177308-0d34-0410-b5e6-96231b3b80d8
commit 95ba1ec4cbb14614f9ac26c9aabe5cac6640c4b0
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 05:00:50 2009 +0000
simplify/detangle some control flow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80476 91177308-0d34-0410-b5e6-96231b3b80d8
commit c0f553e874121b6a0feb35e580040c02da05ac3c
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 04:49:01 2009 +0000
simplify and cleanup some code, remove some code that just
does constant folding of gep's: this is already handled in
a more general way.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80475 91177308-0d34-0410-b5e6-96231b3b80d8
commit 9da50553ef4596ea75c3a5434bf9ad356fb574ee
Author: Chris Lattner <sabre@nondot.org>
Date: Sun Aug 30 04:25:40 2009 +0000
default count-aa to -print-all. The whole reason to use count-aa is
to see what queries are being made by a transformation, we might as well
default to printing them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80474 91177308-0d34-0410-b5e6-96231b3b80d8
commit 09880947395319ff0df656549ddf0b080b7af385
Author: Bill Wendling <isanbard@gmail.com>
Date: Sun Aug 30 00:28:57 2009 +0000
Nuke moribund "std::string" version of EOL(..., Encoding).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80466 91177308-0d34-0410-b5e6-96231b3b80d8
commit cdfb9b17b94bffa0de0e4862d22369fa1dcd9099
Author: Dan Gohman <gohman@apple.com>
Date: Sat Aug 29 23:54:26 2009 +0000
Add AutoGenerated.inc to svn:ignore.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80455 91177308-0d34-0410-b5e6-96231b3b80d8
commit 5d138f96f048cc7009397708ed10edea7cede5a6
Author: Dan Gohman <gohman@apple.com>
Date: Sat Aug 29 23:39:38 2009 +0000
Remove an unnecessary Context argument.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80454 91177308-0d34-0410-b5e6-96231b3b80d8
commit f928ad4af07aaac5e7e81757dcd514acbb5cb39c
Author: Dan Gohman <gohman@apple.com>
Date: Sat Aug 29 23:37:49 2009 +0000
Minor logic simplification.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80453 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3d9354c841746f1802babcd465e542d7a7ea2a10
Author: Dan Gohman <gohman@apple.com>
Date: Sat Aug 29 23:36:57 2009 +0000
Add some comments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80452 91177308-0d34-0410-b5e6-96231b3b80d8
commit 18e06cf39d0313f80b055eb98dba8d8f42fd08cd
Author: Dan Gohman <gohman@apple.com>
Date: Sat Aug 29 23:35:16 2009 +0000
Cleanup whitespace and indentation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80451 91177308-0d34-0410-b5e6-96231b3b80d8
commit b006a1010559be4bc9d5e577c50fc750194f34a6
Author: Dan Gohman <gohman@apple.com>
Date: Sat Aug 29 23:34:14 2009 +0000
Remove some unused fields.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80450 91177308-0d34-0410-b5e6-96231b3b80d8
commit 1596dd23f3e2df5225cdfcea0904a017f96aaa90
Author: Dan Gohman <gohman@apple.com>
Date: Sat Aug 29 22:19:15 2009 +0000
CMOV_GR8 clobbers EFLAGS when its expansion involves an xor to set
a register to 0. This fixes PR4814.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80445 91177308-0d34-0410-b5e6-96231b3b80d8
commit ac09afaf40216429fad53899cce2f9fde8e267d4
Author: Benjamin Kramer <benny.kra@googlemail.com>
Date: Sat Aug 29 13:38:21 2009 +0000
Inline empty destructor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80431 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3c5374802712a3d28cd13207ed3979a95457075c
Author: Bill Wendling <isanbard@gmail.com>
Date: Sat Aug 29 12:31:38 2009 +0000
Fix warning about non-virtual destructor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80429 91177308-0d34-0410-b5e6-96231b3b80d8
commit b4ac493684cdeb2147000a6816a563269fcf3c70
Author: Bill Wendling <isanbard@gmail.com>
Date: Sat Aug 29 12:20:54 2009 +0000
- Add target lowering methods to get the preferred format for the FDE and LSDA
encodings.
- Make some of the values emitted by the FDEs dependent upon the pointer
size. This is in line with how GCC does things. And it has the benefit of
working for Darwin in 64-bit mode now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80428 91177308-0d34-0410-b5e6-96231b3b80d8
commit 946b521498866b3d83c4447c9c0ece6095a56874
Author: Bill Wendling <isanbard@gmail.com>
Date: Sat Aug 29 12:17:53 2009 +0000
Add a form of EOL which emits the text version of a DWARF format encoding. This
doesn't handle all values of the formatting. Those can be added as needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80427 91177308-0d34-0410-b5e6-96231b3b80d8
commit 502c35e863882790a94ad432d0a03c4a7e1a0aad
Author: Bob Wilson <bob.wilson@apple.com>
Date: Sat Aug 29 05:53:25 2009 +0000
PR4795: Remove EEVT::isFP, isInt and isVec types used by TableGen's type
inferencing. As far as I can tell, these are equivalent to the existing
MVT::fAny, iAny and vAny types, and having both of them makes it harder
to reason about and modify the type inferencing code.
The specific problem in PR4795 occurs when updating a vAny type to be fAny
or iAny, or vice versa. Both iAny and fAny include vector types -- they
intersect with the set of types represented by vAny. When merging them,
choose fAny/iAny to represent the intersection. This is not perfect, since
fAny/iAny also include scalar types, but it is good enough for TableGen's
type inferencing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80423 91177308-0d34-0410-b5e6-96231b3b80d8
commit 0ac7faa993d472be4a23e0e58fa6e9372960cfe8
Author: Eric Christopher <echristo@apple.com>
Date: Sat Aug 29 01:12:46 2009 +0000
Make the augmentation size and next set of bytes agree on size,
and make the reference pointer size as it should be.
Fixes an abort on a testcase derived from libunwind's personality
test in 64-bit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80414 91177308-0d34-0410-b5e6-96231b3b80d8
commit 83b551c5efdc49183f744103cd8e22a75117d07f
Author: Jeffrey Yasskin <jyasskin@google.com>
Date: Sat Aug 29 00:44:16 2009 +0000
Fix OProfile support after r80406 changed the DebugInfo interface from
GlobalVariables to MDNodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80411 91177308-0d34-0410-b5e6-96231b3b80d8
commit e54c004ea5ea6c7e89b1cef9531ce05096122bbf
Author: David Goodwin <david_goodwin@apple.com>
Date: Sat Aug 29 00:11:13 2009 +0000
Another stab at fixing up register kill flags after post-RA scheduling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80410 91177308-0d34-0410-b5e6-96231b3b80d8
commit cb7c98d9ef32354166106ff8218fb9fcbb8b2d24
Author: Anton Korobeynikov <asl@math.spbu.ru>
Date: Sat Aug 29 00:08:18 2009 +0000
Do not assert on too wide splats we don't support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80409 91177308-0d34-0410-b5e6-96231b3b80d8
commit 44e0a6cee931258a05b190f9e6e411a6d276c96a
Author: Anton Korobeynikov <asl@math.spbu.ru>
Date: Fri Aug 28 23:41:26 2009 +0000
Add missed extract_element pattern
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80408 91177308-0d34-0410-b5e6-96231b3b80d8
commit 15e723d2c6021bbeacad9baa9c0d946d4a19867e
Author: Devang Patel <dpatel@apple.com>
Date: Fri Aug 28 23:24:31 2009 +0000
Reapply 79977.
Use MDNodes to encode debug info in llvm IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80406 91177308-0d34-0410-b5e6-96231b3b80d8
commit c299914a58baed2d7cf594494dbba60880d476cd
Author: Evan Cheng <evan.cheng@apple.com>
Date: Fri Aug 28 23:18:09 2009 +0000
Let Darwin linker auto-synthesize stubs and lazy-pointers. This deletes a bunch of nasty code in ARM asm printer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80404 91177308-0d34-0410-b5e6-96231b3b80d8
commit a14f4474b2d915579e9e9bd8bf4080d7f25e7dcd
Author: Eric Christopher <echristo@apple.com>
Date: Fri Aug 28 22:33:43 2009 +0000
Nuke trailing whitespace.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80401 91177308-0d34-0410-b5e6-96231b3b80d8
commit c6750c9bc8e555f632777eb1c69793b3b0dc40f6
Author: Daniel Dunbar <daniel@zuster.org>
Date: Fri Aug 28 16:14:46 2009 +0000
Fix creation of .bca libraries with EXPORTED_SYMBOLS_LIST, this was putting the
llvm-ld shell wrapper script in the archive, not the relinked object!
Also, rename the temp file to avoid conflicts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80373 91177308-0d34-0410-b5e6-96231b3b80d8
commit 72d34e1a91e3f2b58559f92e5c1716ba10586bf1
Author: Andreas Neustifter <astifter@gmx.at>
Date: Fri Aug 28 16:13:45 2009 +0000
Read Makefile.config before using LLVMGCC.
See http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090824/085828.html
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80372 91177308-0d34-0410-b5e6-96231b3b80d8
commit ab4193ba50b6b5fcda5e2230e4705676ec07b463
Author: Edwin Török <edwintorok@gmail.com>
Date: Fri Aug 28 16:12:48 2009 +0000
install-sh chmods to 0755 by default, and this causes 'git diff' to show
that all the Makefiles changed mode.
Fix this by tellint install-sh to chmod
only to 0644, these are not executable files after all!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80371 91177308-0d34-0410-b5e6-96231b3b80d8
commit b5cc6d8ae5a5813f059b0f03511b29c101c3a8ba
Author: Anton Korobeynikov <asl@math.spbu.ru>
Date: Fri Aug 28 16:06:41 2009 +0000
Short-term workaround for frame-related weirdness on win64.
Some other minor win64 fixes as well.
Patch by Michael Beck!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80370 91177308-0d34-0410-b5e6-96231b3b80d8
commit 422cc43971693fd61517993472065277cb0cc903
Author: Edwin Török <edwintorok@gmail.com>
Date: Fri Aug 28 14:05:07 2009 +0000
rm needs -f
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80363 91177308-0d34-0410-b5e6-96231b3b80d8
commit da6633bee39686d02cd348b5c79c9dfc14eea6fd
Author: Edwin Török <edwintorok@gmail.com>
Date: Fri Aug 28 13:35:44 2009 +0000
Remove the llvmprof.out from the test output, otherwise running
make check in a non-clean directory causes it to fail (for example when running
make check twice), since execution counts will differ.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80362 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3f10e8664f46c60e4153da5da0ce33cd6b0b2ea3
Author: Andreas Neustifter <astifter@gmx.at>
Date: Fri Aug 28 11:28:24 2009 +0000
Preparation for Optimal Edge Profiling:
This implements the maximum spanning tree algorithm on CFGs according to
weights given by the ProfileEstimator. This is then used to implement Optimal
Edge Profiling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80358 91177308-0d34-0410-b5e6-96231b3b80d8
commit c99a43a3864aee1121af69db21545a3974226d41
Author: Andreas Neustifter <astifter@gmx.at>
Date: Fri Aug 28 10:38:26 2009 +0000
Remove profiling output file because two consecutive runs of make check give
error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80357 91177308-0d34-0410-b5e6-96231b3b80d8
commit 354f75a94252e20f1d61ff7b047f34070dcccfc9
Author: Andreas Neustifter <astifter@gmx.at>
Date: Fri Aug 28 10:07:41 2009 +0000
Removed unnecessary file creation during test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80356 91177308-0d34-0410-b5e6-96231b3b80d8
commit 975ad9a72fa60d0e8946c9ec584eb5c29d14386e
Author: Andreas Neustifter <astifter@gmx.at>
Date: Fri Aug 28 10:00:28 2009 +0000
Pulled all tests into one test. Removed some redundant tests. Rename.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80355 91177308-0d34-0410-b5e6-96231b3b80d8
commit f14af431e0f9724474dfa923ba940ecaf19316c7
Author: Daniel Dunbar <daniel@zuster.org>
Date: Fri Aug 28 08:08:22 2009 +0000
Fix -Asserts warning, round two.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80354 91177308-0d34-0410-b5e6-96231b3b80d8
commit 796a639383578ff065b5c32539c88f9adb5327c2
Author: Daniel Dunbar <daniel@zuster.org>
Date: Fri Aug 28 07:08:47 2009 +0000
llvm-mc: .lsym is more unsupported than unimplemented, pending a use case appearing.
Also, all one of the file level flags are implemented.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80352 91177308-0d34-0410-b5e6-96231b3b80d8
commit 8388a8fed449aa79d848dd2e7b0cf8650e063028
Author: Daniel Dunbar <daniel@zuster.org>
Date: Fri Aug 28 07:08:35 2009 +0000
llvm-mc: Support .comm emission.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80351 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3ab6715ba17ac6726bd92a4514c68c5e58c3c884
Author: Evan Cheng <evan.cheng@apple.com>
Date: Fri Aug 28 06:59:37 2009 +0000
Print a nl before pic labels so they start at a new line. This makes assembly more readable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80350 91177308-0d34-0410-b5e6-96231b3b80d8
commit fd5e315e8d6dca8cab80789552b6bbfef4d960e0
Author: Andreas Neustifter <astifter@gmx.at>
Date: Fri Aug 28 06:48:25 2009 +0000
Since all std::cout is gone, also remove iostream include.
(See http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090824/085620.html)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80349 91177308-0d34-0410-b5e6-96231b3b80d8
commit a2aca168e5c7bbb35569f6f77a3cd4e8bc17520a
Author: Andreas Neustifter <astifter@gmx.at>
Date: Fri Aug 28 06:41:00 2009 +0000
Readded test from r79615, this tests the complete profiling tool chain. Furhter
tests can test only parts of this system.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80348 91177308-0d34-0410-b5e6-96231b3b80d8
commit df98a14701fe2de1d0b83205f32edcdfef8ca141
Author: Daniel Dunbar <daniel@zuster.org>
Date: Fri Aug 28 05:49:21 2009 +0000
llvm-mc: Support .zerofill emission.
- I'm still trying to figure out the cleanest way to implement this and match the assembler, currently there are some substantial differences.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80347 91177308-0d34-0410-b5e6-96231b3b80d8
commit 1c215be1a50bfd6f0b994d61d0c0548fefa52795
Author: Daniel Dunbar <daniel@zuster.org>
Date: Fri Aug 28 05:49:04 2009 +0000
llvm-mc: Tweak section alignment and size computation to match 'as' closer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80345 91177308-0d34-0410-b5e6-96231b3b80d8
commit 91e7ee60faaf7867aebddbf4915e1422c6895337
Author: Daniel Dunbar <daniel@zuster.org>
Date: Fri Aug 28 05:48:54 2009 +0000
llvm-mc: Factor getSectionData out of SwitchSection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80344 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3f952b45c4791659fe6b6addfdc2812f11a21a41
Author: Daniel Dunbar <daniel@zuster.org>
Date: Fri Aug 28 05:48:46 2009 +0000
llvm-mc: Emit .lcomm as .zerofill.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80343 91177308-0d34-0410-b5e6-96231b3b80d8
commit c12c27bdbc93d517025612eab112f28366256839
Author: Daniel Dunbar <daniel@zuster.org>
Date: Fri Aug 28 05:48:29 2009 +0000
llvm-mc: Unique zero fill sections.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80342 91177308-0d34-0410-b5e6-96231b3b80d8
commit 15f1a5cc63c5f08b31c8a67884efd2604067711e
Author: Daniel Dunbar <daniel@zuster.org>
Date: Fri Aug 28 05:48:22 2009 +0000
llvm-mc: Add const to EmitZeroFill section argument.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80341 91177308-0d34-0410-b5e6-96231b3b80d8
commit b6eff3bcb6f481500df60e028ceaff6b60336a1d
Author: Daniel Dunbar <daniel@zuster.org>
Date: Fri Aug 28 05:48:10 2009 +0000
llvm-mc: Fix thinko in emitting values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80340 91177308-0d34-0410-b5e6-96231b3b80d8
commit a8425d44b7ffa3397ac7d010598e9caab54e1ed4
Author: Daniel Dunbar <daniel@zuster.org>
Date: Fri Aug 28 05:48:04 2009 +0000
Add MathExtras.h OffsetToAlignment, like RoundUpToAlignment but returns the
offset to the next aligned integer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80339 91177308-0d34-0410-b5e6-96231b3b80d8
commit c24bcdb66bd5b6904147ac443ca44da2660f9223
Author: Daniel Dunbar <daniel@zuster.org>
Date: Fri Aug 28 05:47:56 2009 +0000
Fix -Asserts warning.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80338 91177308-0d34-0410-b5e6-96231b3b80d8
commit d7e5bacf57cba6f139d726a0c63cb195f38cd39d
Author: Chris Lattner <sabre@nondot.org>
Date: Fri Aug 28 04:48:54 2009 +0000
finish a half formed thought :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80334 91177308-0d34-0410-b5e6-96231b3b80d8
commit ac6a9258ed6e7fa1e1e40ef505799ac54e852be4
Author: Daniel Dunbar <daniel@zuster.org>
Date: Fri Aug 28 03:06:28 2009 +0000
Another NO_RUNTIME_LIBRARIES tweak...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80331 91177308-0d34-0410-b5e6-96231b3b80d8
commit 1497c39481d4d8616d4ba1fb2cde490cfc100baa
Author: Daniel Dunbar <daniel@zuster.org>
Date: Fri Aug 28 02:20:39 2009 +0000
Tweak NO_RUNTIME_LIBS.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80330 91177308-0d34-0410-b5e6-96231b3b80d8
commit c4823b9ee92e32a666e03406c46a530fcdbdda1a
Author: Chris Lattner <sabre@nondot.org>
Date: Fri Aug 28 00:45:47 2009 +0000
Mark Andersen's as experimental.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80328 91177308-0d34-0410-b5e6-96231b3b80d8
commit a8b647dc112f792cb21b0b675e6d2b300207a4fa
Author: Chris Lattner <sabre@nondot.org>
Date: Fri Aug 28 00:43:14 2009 +0000
Fix PR3913, patch by Jakub Staszak!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80327 91177308-0d34-0410-b5e6-96231b3b80d8
commit 5e1d21856de4bf387cccf8365885c45c87642dfb
Author: Evan Cheng <evan.cheng@apple.com>
Date: Fri Aug 28 00:31:43 2009 +0000
v4, v5 does not support sxtb / sxth.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80322 91177308-0d34-0410-b5e6-96231b3b80d8
commit 66f3f9e7356761c91f8063a38b37293ce750c1c2
Author: Bob Wilson <bob.wilson@apple.com>
Date: Fri Aug 28 00:21:13 2009 +0000
Disable optional bindings for Apple-style builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80319 91177308-0d34-0410-b5e6-96231b3b80d8
commit dc8f15c7a771649ab75bdf2dea1b27067ee9f269
Author: Bob Wilson <bob.wilson@apple.com>
Date: Fri Aug 28 00:10:15 2009 +0000
Revert 76080. This broke some powerpc cross compiles.
It also makes the llvmCore build dependent on whatever version of llvm-gcc
happens to be installed on the build machine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80316 91177308-0d34-0410-b5e6-96231b3b80d8
commit 6decb644026d266aaed9bc51e5840529a4af8df0
Author: Daniel Dunbar <daniel@zuster.org>
Date: Thu Aug 27 23:58:10 2009 +0000
Revert r80305, I forgot a dependent change.
--- Reverse-merging r80305 into '.':
U tools/llvm-mc/AsmParser.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80309 91177308-0d34-0410-b5e6-96231b3b80d8
commit 20b3210d23b9c5633787e3d8bbd98d7cc0083c32
Author: Devang Patel <dpatel@apple.com>
Date: Thu Aug 27 23:51:51 2009 +0000
Closure is a very generic name. Use AppleBlock instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80307 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3edc5f01bcfec50757d8cbdb7cd0fb6abb561d67
Author: Daniel Dunbar <daniel@zuster.org>
Date: Thu Aug 27 23:45:06 2009 +0000
llvm-mc: Unique sections in .zerofill.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80305 91177308-0d34-0410-b5e6-96231b3b80d8
commit ab36e15e689a516f8ff2af4c2c0210a90a423652
Author: Gabor Greif <ggreif@gmail.com>
Date: Thu Aug 27 23:44:33 2009 +0000
eliminate all 80-col violations that I have introduced in my recent checkins (and some others more)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80304 91177308-0d34-0410-b5e6-96231b3b80d8
commit 41d850e034d4f33728c8d8d51a3811dbe0fccf8c
Author: Daniel Dunbar <daniel@zuster.org>
Date: Thu Aug 27 23:43:28 2009 +0000
Don't build runtime libraries in an Apple style build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80303 91177308-0d34-0410-b5e6-96231b3b80d8
commit f5b6d86316d71c3eae687ecb56abfdfd12679a54
Author: Bruno Cardoso Lopes <bruno.cardoso@gmail.com>
Date: Thu Aug 27 19:57:56 2009 +0000
Revert 80278 for now, it caused a lot of MIPS tests to fail
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80280 91177308-0d34-0410-b5e6-96231b3b80d8
commit 862f67b71f0aaeccdd24a0cbd4d99a9a9413c43a
Author: Bruno Cardoso Lopes <bruno.cardoso@gmail.com>
Date: Thu Aug 27 19:40:40 2009 +0000
Revamp our friend Mips :)
Add MO flags to simplify the printing of relocations.
Remove the support for printing large code model relocs (which
aren't supported anyway).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80278 91177308-0d34-0410-b5e6-96231b3b80d8
commit 90adb6c4bd8c285660db59e5ac10fd71fa3c1076
Author: Dan Gohman <gohman@apple.com>
Date: Thu Aug 27 18:16:24 2009 +0000
Don't mark CMOV_GR8 as two-address, or commutable, since it's a pseudo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80271 91177308-0d34-0410-b5e6-96231b3b80d8
commit fa4c3253f6dd9f328549aa73e2710981ac3a2881
Author: Dan Gohman <gohman@apple.com>
Date: Thu Aug 27 18:14:26 2009 +0000
Adjust the MachineBasicBlock verifier rules to be more
tolerant of blocks that end with "unreachable".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80270 91177308-0d34-0410-b5e6-96231b3b80d8
commit 20391ca63ee850ffd6fb86bfd058ff61b698197d
Author: Eric Christopher <echristo@apple.com>
Date: Thu Aug 27 18:08:16 2009 +0000
Add FIXME for when we support more specific XMM registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80269 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3d82bbd2ddfb775d59f271cc25cade73551f976c
Author: Eric Christopher <echristo@apple.com>
Date: Thu Aug 27 18:07:15 2009 +0000
Nuke trailing whitespace.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80268 91177308-0d34-0410-b5e6-96231b3b80d8
commit f8b840f45084d2486be3fd074807d9a37564a33d
Author: Dan Gohman <gohman@apple.com>
Date: Thu Aug 27 18:02:03 2009 +0000
Use stripPointerCasts instead of doing the same manually.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80267 91177308-0d34-0410-b5e6-96231b3b80d8
commit a578538e9fde98cb05ce9740d7c63aafbd1c69f4
Author: Dan Gohman <gohman@apple.com>
Date: Thu Aug 27 17:59:08 2009 +0000
Minor code simplification.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80266 91177308-0d34-0410-b5e6-96231b3b80d8
commit c99596ddbf78116260c177edcfad9261bf186b68
Author: Dan Gohman <gohman@apple.com>
Date: Thu Aug 27 17:55:13 2009 +0000
Teach getUnderlyingObject and skipPointerCasts about GlobalAliases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80265 91177308-0d34-0410-b5e6-96231b3b80d8
commit fe1256903404065be182735c1402411c4940e9e5
Author: Dan Gohman <gohman@apple.com>
Date: Thu Aug 27 17:54:15 2009 +0000
Be somewhat more consistent about const qualifiers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80264 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3c8455152e3d41b8e5f7b33c3ed99c7a8105f5a8
Author: Dan Gohman <gohman@apple.com>
Date: Thu Aug 27 17:52:56 2009 +0000
Global Aliases are not identifiable objects.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80263 91177308-0d34-0410-b5e6-96231b3b80d8
commit 54e98d921f7eabfd3baae5399e835ddc39a75e6c
Author: Dan Gohman <gohman@apple.com>
Date: Thu Aug 27 17:51:25 2009 +0000
Handle TargetData with const.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80262 91177308-0d34-0410-b5e6-96231b3b80d8
commit ec966442362eeff9b24c9eee2b11188ab4a5246b
Author: Dan Gohman <gohman@apple.com>
Date: Thu Aug 27 17:29:49 2009 +0000
Strip trailing whitespace from blank lines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80259 91177308-0d34-0410-b5e6-96231b3b80d8
commit 7bec0f5f90c6d917beb4b1433c847aa132cdfacf
Author: Gabor Greif <ggreif@gmail.com>
Date: Thu Aug 27 17:07:35 2009 +0000
re-apply r80197, now that iterator.h is not mentioned any more
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80254 91177308-0d34-0410-b5e6-96231b3b80d8
commit aa152ae811d8e0ffd01c7a8b454d595cb1a1a31f
Author: Anton Korobeynikov <asl@math.spbu.ru>
Date: Thu Aug 27 16:25:49 2009 +0000
Hopefully the final missing part :(
scalar_to_vector is fully legal now
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80251 91177308-0d34-0410-b5e6-96231b3b80d8
commit 872393c20ee29eaae1746deed115f06192526f64
Author: Anton Korobeynikov <asl@math.spbu.ru>
Date: Thu Aug 27 16:10:17 2009 +0000
Forgot about actual change :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80250 91177308-0d34-0410-b5e6-96231b3b80d8
commit 0a21bce095161b98a3671b2aa0e63a020b03e120
Author: Anton Korobeynikov <asl@math.spbu.ru>
Date: Thu Aug 27 16:04:47 2009 +0000
scalar_to_vector is fully legal now (implemented as subreg accesses)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80249 91177308-0d34-0410-b5e6-96231b3b80d8
commit 2b6e274f8669337cb148c1df4e060a41af14cc1e
Author: Devang Patel <dpatel@apple.com>
Date: Thu Aug 27 15:32:38 2009 +0000
Remove an entry from ValueMap before removing elements.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80247 91177308-0d34-0410-b5e6-96231b3b80d8
commit 6e8275030925dbd3beeb873d0bf605f0c0c67f0b
Author: Anton Korobeynikov <asl@math.spbu.ru>
Date: Thu Aug 27 14:51:42 2009 +0000
Ok, sometimes it's profitable to turn scalar_to_vector stuff into subreg access.
Add a testcase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80246 91177308-0d34-0410-b5e6-96231b3b80d8
commit baee7b2a5501a45a59554b5bafd87264a2edc442
Author: Anton Korobeynikov <asl@math.spbu.ru>
Date: Thu Aug 27 14:38:44 2009 +0000
Transform float scalar_to_vector into subreg accesses.
No idea whether this is profitable or not.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80245 91177308-0d34-0410-b5e6-96231b3b80d8
commit 9daa0677ac901b0f54bdba31dc3913b92df58e50
Author: Misha Brukman <brukman+llvm@gmail.com>
Date: Thu Aug 27 14:14:21 2009 +0000
STRD and LDRD require ARMv5TE, not just ARMv5T.
See http://llvm.org/PR4687 for more info and links.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80244 91177308-0d34-0410-b5e6-96231b3b80d8
commit 4dd75744b70c1a3f686ce5a43952124fb0de7ad9
Author: Benjamin Kramer <benny.kra@googlemail.com>
Date: Thu Aug 27 12:02:34 2009 +0000
Inverse logic to increase portability.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80240 91177308-0d34-0410-b5e6-96231b3b80d8
commit 07f1cdae7f327c15cdfc0d68c8500a275dba72b2
Author: Sanjiv Gupta <sanjiv.gupta@microchip.com>
Date: Thu Aug 27 11:54:38 2009 +0000
To make mcc16 run correctly on mac.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80239 91177308-0d34-0410-b5e6-96231b3b80d8
commit 006e46ee524c49f00fdfa4d0b582c7ecd693c95b
Author: Daniel Dunbar <daniel@zuster.org>
Date: Thu Aug 27 08:17:51 2009 +0000
llvm-mc/Mach-O: Add MCCodeEmitter support, for encoding instructions.
- No relocations yet, of course.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80235 91177308-0d34-0410-b5e6-96231b3b80d8
commit 2f37963b50b496c99300850683ed41db4f9431b6
Author: Daniel Dunbar <daniel@zuster.org>
Date: Thu Aug 27 08:12:55 2009 +0000
llvm-mc/X86: Implement single instruction encoding interface for MC.
- Note, this is a gigantic hack, with the sole purpose of unblocking further
work on the assembler (its also possible to test the mathcer more completely
now).
- Despite being a hack, its actually good enough to work over all of 403.gcc
(although some encodings are probably incorrect). This is a testament to the
beauty of X86's MachineInstr, no doubt! ;)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80234 91177308-0d34-0410-b5e6-96231b3b80d8
commit 1f32816fdaf9ba3a7e6e5705f94be145fafde497
Author: Daniel Dunbar <daniel@zuster.org>
Date: Thu Aug 27 07:58:57 2009 +0000
llvm-mc: Print encodings after the instruction, and only when we have an asm
printer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80233 91177308-0d34-0410-b5e6-96231b3b80d8
commit 75513bd24edb8ea2142145b448df7a4cdaeaa335
Author: Daniel Dunbar <daniel@zuster.org>
Date: Thu Aug 27 07:58:05 2009 +0000
X86: Mark EH_RETURN as code-gen-only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80232 91177308-0d34-0410-b5e6-96231b3b80d8
commit 0125384b4a902da228354e5a201cd4cf4f2f1a4a
Author: Daniel Dunbar <daniel@zuster.org>
Date: Thu Aug 27 07:57:12 2009 +0000
Add {MCInst,MCOperand}::{print,dump}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80231 91177308-0d34-0410-b5e6-96231b3b80d8
commit 160f252aa8189beba57b0b025b0206a3910c4ae9
Author: Daniel Dunbar <daniel@zuster.org>
Date: Thu Aug 27 07:56:39 2009 +0000
llvm-mc: Only show instruction encodings with --show-encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80230 91177308-0d34-0410-b5e6-96231b3b80d8
commit f449eb343e70f1e4e8f982939d53c083a1bc5ba3
Author: Gabor Greif <ggreif@gmail.com>
Date: Thu Aug 27 06:59:20 2009 +0000
the buildbots revealed one more breakage. fix. (why didn't I see this?)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80227 91177308-0d34-0410-b5e6-96231b3b80d8
commit 765f012f22956a3085e1e84441af9d880bf65f35
Author: Gabor Greif <ggreif@gmail.com>
Date: Thu Aug 27 06:41:46 2009 +0000
Clean up the minor mess I caused with removing iterator.h. I shall take care of 80-col violations and the FIXME later. (Thanks goodness that I live in another continent, so the monkeypox did not strike me :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80224 91177308-0d34-0410-b5e6-96231b3b80d8
commit bc42440879f2a302f2801e224828cfdccd5a92a7
Author: Chris Lattner <sabre@nondot.org>
Date: Thu Aug 27 06:29:33 2009 +0000
Implement a new optimization in the inliner: if inlining multiple
calls into a function and if the calls bring in arrays, try to merge
them together to reduce stack size. For example, in the testcase
we'd previously end up with 4 allocas, now we end up with 2 allocas.
As described in the comments, this is not really the ideal solution
to this problem, but it is surprisingly effective. For example, on
176.gcc, we end up eliminating 67 arrays at "gccas" time and another
24 at "llvm-ld" time.
One piece of concern that I didn't look into: at -O0 -g with
forced inlining this will almost certainly result in worse debug
info. I think this is acceptable though given that this is a case
of "debugging optimized code", and we don't want debug info to
prevent the optimizer from doing things anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80215 91177308-0d34-0410-b5e6-96231b3b80d8
commit 2d1272cbbc0ba9bffbc702e67c59a8d12ec93660
Author: Chris Lattner <sabre@nondot.org>
Date: Thu Aug 27 06:20:45 2009 +0000
the inliner shouldn't crash on this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80214 91177308-0d34-0410-b5e6-96231b3b80d8
commit ea3bccb555f65187ecbb134d26aab8103ca167b2
Author: Daniel Dunbar <daniel@zuster.org>
Date: Thu Aug 27 06:11:15 2009 +0000
For now, only run MC tests if X86 is configured.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80213 91177308-0d34-0410-b5e6-96231b3b80d8
commit 17d1a4db879f7af0fd20dd78f704ff9f82aabbe1
Author: Bill Wendling <isanbard@gmail.com>
Date: Thu Aug 27 05:49:50 2009 +0000
This is passing for PPC on Mac OS X.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80210 91177308-0d34-0410-b5e6-96231b3b80d8
commit cf5d1d8ceb34c56f21bd3f41f5329407e8d090ce
Author: Bill Wendling <isanbard@gmail.com>
Date: Thu Aug 27 05:35:28 2009 +0000
Revert accidental commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80208 91177308-0d34-0410-b5e6-96231b3b80d8
commit f659a56d993743e0d51beb2c94fbe187637e5918
Author: Chris Lattner <sabre@nondot.org>
Date: Thu Aug 27 04:43:05 2009 +0000
unbreak the build, yay for symlinks + makefiles. :(
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80205 91177308-0d34-0410-b5e6-96231b3b80d8
commit d1586b1a1d27d5efeb8e487bbeb7ed255159e53b
Author: Chris Lattner <sabre@nondot.org>
Date: Thu Aug 27 04:32:07 2009 +0000
reduce header #include'age
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80204 91177308-0d34-0410-b5e6-96231b3b80d8
commit 1ba292d8cfe7b5bf705c5bb307f63f0c0bbe8979
Author: Chris Lattner <sabre@nondot.org>
Date: Thu Aug 27 04:20:52 2009 +0000
enhance InlineFunction to be able to optionally return
a the list of static allocas that it inlined.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80203 91177308-0d34-0410-b5e6-96231b3b80d8
commit eb87590c5346b7c17032242e2232a6c1d217f964
Author: Chris Lattner <sabre@nondot.org>
Date: Thu Aug 27 04:02:30 2009 +0000
smallvectorize the list of returns built by CloneAndPruneFunctionInto.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80202 91177308-0d34-0410-b5e6-96231b3b80d8
commit 612956220f38126feaacceb378cf105043739271
Author: Chris Lattner <sabre@nondot.org>
Date: Thu Aug 27 03:56:43 2009 +0000
remove CloneTrace, which appears to be dead since 2004.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80201 91177308-0d34-0410-b5e6-96231b3b80d8
commit ae56c0de911bf5328ffda48e51ce37bcd7aa0d76
Author: Chris Lattner <sabre@nondot.org>
Date: Thu Aug 27 03:51:50 2009 +0000
reduce inlining factor some stuff out to a static helper function,
and other code cleanups. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80199 91177308-0d34-0410-b5e6-96231b3b80d8
commit 5537c20c55869fac64e4f5738f8eab2080cc79c6
Author: Bill Wendling <isanbard@gmail.com>
Date: Thu Aug 27 03:32:50 2009 +0000
Revert accidental commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80198 91177308-0d34-0410-b5e6-96231b3b80d8
commit 25cd944a98bcf3b1542c71d2654fe61e28562867
Author: Bill Wendling <isanbard@gmail.com>
Date: Thu Aug 27 03:29:26 2009 +0000
--- Reverse-merging r80147 into '.':
A include/llvm/ADT/iterator.cmake
U autoconf/configure.ac
--- Reverse-merging r80161 into '.':
U cmake/config-ix.cmake
--- Reverse-merging r80171 into '.':
U Makefile
--- Reverse-merging r80173 into '.':
U configure
U include/llvm/Config/config.h.in
--- Reverse-merging r80180 into '.':
A include/llvm/ADT/iterator.h.in
Despite common miscomceptions, iterator.h is alive and well. It broke the build
bots for several hours. And yet no one bothered to look at them.
Gabor and Doug, please review your changes and make sure that they actually
build before resubmitting them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80197 91177308-0d34-0410-b5e6-96231b3b80d8
commit 0d0598f6281c0b1ae107b2fa2fabd69ec21263c4
Author: Dan Gohman <gohman@apple.com>
Date: Thu Aug 27 02:43:49 2009 +0000
Add some checks for MachineCFG consistency. Use AnalyzeBranch and
do extra checking when it succeeds, as those are cases where
CodeGen will be doing particularly interesting CFG modifications.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80196 91177308-0d34-0410-b5e6-96231b3b80d8
commit 92e5548870b7945deb93f7956ea816f67d34b73f
Author: Daniel Dunbar <daniel@zuster.org>
Date: Thu Aug 27 02:08:37 2009 +0000
Update CMake
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80195 91177308-0d34-0410-b5e6-96231b3b80d8
commit 2f377df6bba8110c3bc0bf5185d33d1f46b54c6b
Author: Daniel Dunbar <daniel@zuster.org>
Date: Thu Aug 27 01:34:22 2009 +0000
llvm-mc: Tweak MCCodeEmitter skeleton.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80193 91177308-0d34-0410-b5e6-96231b3b80d8
commit cdde2975f55c43493f3318630985e7a1e8e14384
Author: Dan Gohman <gohman@apple.com>
Date: Thu Aug 27 01:25:57 2009 +0000
Initialize the PoisonMemory member before initializing
members that call methods that read the PoisonMemory member.
This fixes potential spurious (though probably otherwise
harmless) poising of unused memory, and fixes the
associated valgrind error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80192 91177308-0d34-0410-b5e6-96231b3b80d8
commit 363cd759d4186bdae7b49e89a0d434749d6198aa
Author: Evan Cheng <evan.cheng@apple.com>
Date: Thu Aug 27 01:23:50 2009 +0000
Fix PR4789. Teach eliminateFrameIndex how to handle VLDRQ and VSTRQ which cannot fold any immediate offset.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80191 91177308-0d34-0410-b5e6-96231b3b80d8
commit 511e71114c34c8ddae2b44b996502a5efe1adc3a
Author: Daniel Dunbar <daniel@zuster.org>
Date: Thu Aug 27 01:15:54 2009 +0000
Add missing declarations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80190 91177308-0d34-0410-b5e6-96231b3b80d8
commit 12266adfd9dc571aafb7ec7f8b69d85c7a6e352a
Author: Daniel Dunbar <daniel@zuster.org>
Date: Thu Aug 27 00:51:57 2009 +0000
Sketch TargetRegistry support for MCCodeEmitter abstract interface.
- Of course, nothing actually can provide this interface yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80188 91177308-0d34-0410-b5e6-96231b3b80d8
commit adb77e4c37d183af9a2f29b6df8b0dfee562bbba
Author: Daniel Dunbar <daniel@zuster.org>
Date: Thu Aug 27 00:38:04 2009 +0000
Try to make MSVC just a little happier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80187 91177308-0d34-0410-b5e6-96231b3b80d8
commit b59f15a1d2c40f978d93f43b006546f455a65f04
Author: Dan Gohman <gohman@apple.com>
Date: Thu Aug 27 00:31:47 2009 +0000
X86FastISel support for loading and storing values of type i1.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80186 91177308-0d34-0410-b5e6-96231b3b80d8
commit 29b998f5248398e6cfe323a5ebd7419bb77975b4
Author: Dan Gohman <gohman@apple.com>
Date: Thu Aug 27 00:14:12 2009 +0000
Expand i8 selects into control flow instead of 16-bit conditional
moves. This avoids the need to promote the operands (or implicitly
extend them, a partial register update condition), and can reduce
i8 register pressure. This substantially speeds up code such as
write_hex in lib/Support/raw_ostream.cpp.
subclass-coalesce.ll is too trivial and no longer tests what it was
originally intended to test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80184 91177308-0d34-0410-b5e6-96231b3b80d8
commit a7bddb52ed1bb68e8c654c522b885f941c540d04
Author: Gabor Greif <ggreif@gmail.com>
Date: Wed Aug 26 23:35:33 2009 +0000
now that include/llvm/ADT/iterator.h.in is not attempted to be built, its prerequisite can go away too
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80180 91177308-0d34-0410-b5e6-96231b3b80d8
commit b5b99e6fa820047460b362d5d981766ac313b1ce
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 23:12:33 2009 +0000
Simplify.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80176 91177308-0d34-0410-b5e6-96231b3b80d8
commit 2eff5fff4d600df3d29f74dd195bc564a48206b4
Author: Douglas Gregor <doug.gregor@gmail.com>
Date: Wed Aug 26 22:59:05 2009 +0000
Regenerate configure
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80173 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3eace462948ecfec5ee53127c445e4d0d5f1ae89
Author: Gabor Greif <ggreif@gmail.com>
Date: Wed Aug 26 22:55:19 2009 +0000
eliminate references to ADT/iterator.h
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80171 91177308-0d34-0410-b5e6-96231b3b80d8
commit d68b1af98ca9bb39ac51d046a37266ceb24e38b5
Author: Owen Anderson <resistor@mac.com>
Date: Wed Aug 26 22:55:11 2009 +0000
Make this into a static method.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80170 91177308-0d34-0410-b5e6-96231b3b80d8
commit 2f01e9983a054713a49d2ac2124e8ca26d128574
Author: Bob Wilson <bob.wilson@apple.com>
Date: Wed Aug 26 22:50:39 2009 +0000
Fix bad length argument to substr calls. Apparently I'm the first one to
attempt more than 2 constraints on an instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80169 91177308-0d34-0410-b5e6-96231b3b80d8
commit 418706d9a8a304630ddecc3709598d823bee8188
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 22:49:51 2009 +0000
llvm-mc/Mach-O: Unique sections properly, so we don't get duplicate text
sections, etc.
- The quick and dirty way, just clone the TargetLoweringObjectFile
code. Eventually this should be shared... somehow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80168 91177308-0d34-0410-b5e6-96231b3b80d8
commit 1ea86df7ddb44659fbf694934abb2177beed8637
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 22:13:22 2009 +0000
llvm-mc/Mach-O: Don't put assembler temporary labels in the symbol table.
- I moved section creation back into AsmParser. I think policy decisions like
this should be pushed higher, not lower, when possible (in addition the
assembler has flags which change this behavior, for example).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80162 91177308-0d34-0410-b5e6-96231b3b80d8
commit b003759e247f0edb3b691849598ba252f51ae624
Author: Douglas Gregor <doug.gregor@gmail.com>
Date: Wed Aug 26 22:12:02 2009 +0000
De-bork CMake build
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80161 91177308-0d34-0410-b5e6-96231b3b80d8
commit e92cc8d5591cb7ded636c91cc98c741af62ec85f
Author: Eric Christopher <echristo@apple.com>
Date: Wed Aug 26 21:44:57 2009 +0000
Rework getPersonalityIndex slightly - 0 is now a valid and not-NULL
personality function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80153 91177308-0d34-0410-b5e6-96231b3b80d8
commit 2a1099a6809307eee7521b1f725ef89370f7ebd1
Author: Gabor Greif <ggreif@gmail.com>
Date: Wed Aug 26 21:36:59 2009 +0000
nobody includes llvm/ADT/iterator.h any more,
so get rid of this monstrosity. iterator.h.in is scheduled for deletion in my working copy,
but I wait till I see that configure gets regenerated, as it depends on it. I'll commit
then.
There are still some AC_* tests in the configure.ac dealing with iterators, those can
be zapped probably too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80147 91177308-0d34-0410-b5e6-96231b3b80d8
commit c87d5ae938fe0c3b0afc3aefef1dc6a9873516e4
Author: Eric Christopher <echristo@apple.com>
Date: Wed Aug 26 21:30:49 2009 +0000
If we're emitting additional CIEs due to personality functions
don't emit the default one. Explicitly check for the NULL
CIE later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80146 91177308-0d34-0410-b5e6-96231b3b80d8
commit 84603633a7609ec55de5d8145048efbbf45e5c9c
Author: Eric Christopher <echristo@apple.com>
Date: Wed Aug 26 21:27:09 2009 +0000
Nuke trailing whitespace.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80145 91177308-0d34-0410-b5e6-96231b3b80d8
commit f8c4bb7da634d77a7f2cff601b8d3f53c143e9ad
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 21:22:22 2009 +0000
llvm-mc/Mach-O: Set .subsections_via_symbols flag properly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80144 91177308-0d34-0410-b5e6-96231b3b80d8
commit 87f46499f001931c031002473a73793772852e51
Author: Bill Wendling <isanbard@gmail.com>
Date: Wed Aug 26 21:00:34 2009 +0000
Don't submit test directory.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80139 91177308-0d34-0410-b5e6-96231b3b80d8
commit 441e205eb82a0ebd70b807d8560c5a76188eabc5
Author: Reid Kleckner <reid@kleckner.net>
Date: Wed Aug 26 20:58:25 2009 +0000
Allocate the module provider in the Kaleidoscope code on the heap, not the stack, so that it can be properly deleted. Also update the tutorial with the new code. This fixes PR4762, hopefully better than the last time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80138 91177308-0d34-0410-b5e6-96231b3b80d8
commit 4952aa5163ff4e87910d461f06316cc793ca95b8
Author: Gabor Greif <ggreif@gmail.com>
Date: Wed Aug 26 19:16:32 2009 +0000
Remove all the LLVM_COMPACTIFY_SENTINELS-related macro magic as discussed with Chris on IRC. Anybody wanting to debug sentinel dereferencing problems must revert this patch and perform the indicated modifications.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80128 91177308-0d34-0410-b5e6-96231b3b80d8
commit ffefef35790db7819c72ba7e53c73b8e5931e851
Author: Oscar Fuentes <ofv@wanadoo.es>
Date: Wed Aug 26 18:37:05 2009 +0000
CMake: Removed outdated TODO.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80124 91177308-0d34-0410-b5e6-96231b3b80d8
commit 66448030685cdc3c9bfd52449e4027258aaba480
Author: Venkatraman Govindaraju <venkatra@cs.wisc.edu>
Date: Wed Aug 26 18:24:12 2009 +0000
Generate section for bss and enable weak symbols
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80121 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3a392c8714c745ffdc77da0a8589c7b0df03515f
Author: Bob Wilson <bob.wilson@apple.com>
Date: Wed Aug 26 18:11:50 2009 +0000
Convert some more Neon tests to FileCheck.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80120 91177308-0d34-0410-b5e6-96231b3b80d8
commit 5e69950d5391bdf294b415bf39dd44f9f40556a1
Author: Dale Johannesen <dalej@apple.com>
Date: Wed Aug 26 18:10:32 2009 +0000
Alter 79292 to produce output that actually assembles.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80119 91177308-0d34-0410-b5e6-96231b3b80d8
commit 23f2034aaff80f52b309ee17bfa7a9fc801c9677
Author: Mike Stump <mrs@apple.com>
Date: Wed Aug 26 18:02:19 2009 +0000
Allow unsigned long long DenseMapInfo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80118 91177308-0d34-0410-b5e6-96231b3b80d8
commit b1b88455b18224867a8d2fc6c3202b6ce12e0a1c
Author: Bob Wilson <bob.wilson@apple.com>
Date: Wed Aug 26 17:39:53 2009 +0000
Remove unneeded ARM-specific DAG nodes for VLD* and VST* Neon operations.
The instructions can be selected directly from the intrinsics. We will need
to add some ARM-specific nodes for VLD/VST of 3 and 4 128-bit vectors, but
those are not yet implemented.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80117 91177308-0d34-0410-b5e6-96231b3b80d8
commit 0defefd8ce9f13cecba8c988897c3224a25e96f8
Author: Anton Korobeynikov <asl@math.spbu.ru>
Date: Wed Aug 26 17:39:40 2009 +0000
Add extload expansion for f128
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80116 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3e72169c1b197ef8c5b4c663e2eee4551a3a7178
Author: Anton Korobeynikov <asl@math.spbu.ru>
Date: Wed Aug 26 17:39:23 2009 +0000
Unbreak FP128 stuff in cbe
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80115 91177308-0d34-0410-b5e6-96231b3b80d8
commit 644cdc3c64cb485c6a21d1bfb126c107e5b40d64
Author: Oscar Fuentes <ofv@wanadoo.es>
Date: Wed Aug 26 17:05:06 2009 +0000
Ignore -fPIC test on Windows. Suggested by Yonggang Luo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80111 91177308-0d34-0410-b5e6-96231b3b80d8
commit 8427b6b0529e66663737b39ea51a1fbdbbbbd534
Author: Douglas Gregor <doug.gregor@gmail.com>
Date: Wed Aug 26 16:33:57 2009 +0000
Unbreak CMake build
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80109 91177308-0d34-0410-b5e6-96231b3b80d8
commit 886f20275a78a1b03b83a8145a62f5e4cfbb1c99
Author: Anton Korobeynikov <asl@math.spbu.ru>
Date: Wed Aug 26 16:26:09 2009 +0000
Expand scalar_to_vector - we don't have any isel logic for it now
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80107 91177308-0d34-0410-b5e6-96231b3b80d8
commit 75c687bcc528eb81dc693d63f7aff9185b29e56f
Author: Dan Gohman <gohman@apple.com>
Date: Wed Aug 26 16:06:11 2009 +0000
Add comments detailing a known bug, so that people writing other
backends don't use it as an example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80105 91177308-0d34-0410-b5e6-96231b3b80d8
commit 32b17ffaa8593d25728c9ebad7e82a45c16f817c
Author: Dan Gohman <gohman@apple.com>
Date: Wed Aug 26 15:57:57 2009 +0000
-fast is now -O0. -fast-isel is no longer experimental.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80104 91177308-0d34-0410-b5e6-96231b3b80d8
commit 4637d177299aed45c6be7ca24e003771f33fd5d6
Author: Dan Gohman <gohman@apple.com>
Date: Wed Aug 26 15:56:38 2009 +0000
Move ProfileInfo::Edge's operator<< out of line. Among other benefits,
this eliminates the ATTRIBUTE_USED, which wasn't being used in a manner
acceptable to some GCC versions, according to the buildbots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80103 91177308-0d34-0410-b5e6-96231b3b80d8
commit a064a395489f954b0eaafb351d15b456699dea8e
Author: Andreas Neustifter <astifter@gmx.at>
Date: Wed Aug 26 15:18:38 2009 +0000
Bugfix for r80100, forgot include. Sorry.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80101 91177308-0d34-0410-b5e6-96231b3b80d8
commit 70eeb51888ed9e73d058a3b0c889c295219e2109
Author: Andreas Neustifter <astifter@gmx.at>
Date: Wed Aug 26 15:13:44 2009 +0000
Implemented comments from Daniel Dunbar.
(See http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090817/084958.html)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80100 91177308-0d34-0410-b5e6-96231b3b80d8
commit 9959b052347ceddec3576013485f2564b99b944e
Author: Dan Gohman <gohman@apple.com>
Date: Wed Aug 26 14:59:13 2009 +0000
Don't use INSERT_SUBREG to model anyext operations on x86-64, as it
leads to partial-register definitions. To help avoid redundant
zero-extensions, also teach the h-register matching patterns that
use movzbl to match anyext as well as zext.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80099 91177308-0d34-0410-b5e6-96231b3b80d8
commit 9927f829a68b645ed5813b25e21a881d94fc80d8
Author: Dan Gohman <gohman@apple.com>
Date: Wed Aug 26 14:53:06 2009 +0000
Create a ScalarEvolution-based AliasAnalysis implementation.
This is a simple AliasAnalysis implementation which works by making
ScalarEvolution queries. ScalarEvolution has a more complete understanding
of arithmetic than BasicAA's collection of ad-hoc checks, so it handles
some cases that BasicAA misses, for example p[i] and p[i+1] within the
same iteration of a loop.
This is currently experimental. It may be that the main use for this pass
will be to help find cases where BasicAA can be profitably extended, or
to help in the development of the overall AliasAnalysis infrastructure,
however it's also possible that it could grow up to become a directly
useful pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80098 91177308-0d34-0410-b5e6-96231b3b80d8
commit 596114dc06489e5bd79e3e8ffc60d43bbf3668e3
Author: Dan Gohman <gohman@apple.com>
Date: Wed Aug 26 14:34:12 2009 +0000
Fix a missing newline, now that Value's operator<< doesn't add one of its own.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80096 91177308-0d34-0410-b5e6-96231b3b80d8
commit 84c793aef4170e0d5be4d2c6fcb26a9e56cad21b
Author: Dan Gohman <gohman@apple.com>
Date: Wed Aug 26 14:32:17 2009 +0000
Use SetVector instead of std::set so that alias relations are tested and
printed in a deterministic order.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80095 91177308-0d34-0410-b5e6-96231b3b80d8
commit 8fa9da2b34655a15102a0845617a9951ee945ed6
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 13:58:10 2009 +0000
llvm-mc/Mach-O: Add support for relocations.
- I haven't really tried to find the "right" way to store the fixups or apply
them, yet. This works, but isn't particularly elegant or fast.
- Still no evaluation support, so we don't actually ever not turn a fixup into
a relocation entry.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80089 91177308-0d34-0410-b5e6-96231b3b80d8
commit c3c1992d46f418c45a8e0b5fdb3c452c90aa960e
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 13:57:54 2009 +0000
llvm-mc/Mach-O: Move symbol indices into the MCSymbolData structure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80088 91177308-0d34-0410-b5e6-96231b3b80d8
commit cefbda1f46cc612e074fdcc1d8aab712aba085e7
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 13:57:44 2009 +0000
llvm-mc/Mach-O: Dump relocations and section data (optionally) in my Mach-O dumper.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80087 91177308-0d34-0410-b5e6-96231b3b80d8
commit 4486ac16542e9dd843778c5f684e1cd9d7bb3945
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 13:57:37 2009 +0000
llvm-mc: Add symbol entries for undefined symbols used in .fill and .org.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80086 91177308-0d34-0410-b5e6-96231b3b80d8
commit 7c672df8b969b7514438228bed80cfad6e9c473e
Author: Anton Korobeynikov <asl@math.spbu.ru>
Date: Wed Aug 26 13:44:29 2009 +0000
Add dummy inline asm handling for 'r' constraint. This fixes PR4778
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80085 91177308-0d34-0410-b5e6-96231b3b80d8
commit 39fd40ae8671ecff6a1857b5a0156e52284c4e5c
Author: Andreas Neustifter <astifter@gmx.at>
Date: Wed Aug 26 13:33:09 2009 +0000
Moved isDeclaration() check further down to allow for function counts for
declarations if necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80084 91177308-0d34-0410-b5e6-96231b3b80d8
commit 92183c031a21857a580b38795272ce80863b9ebf
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 09:16:57 2009 +0000
llvm-mc: Change MCContext value table to take const MCSymbol*s.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80079 91177308-0d34-0410-b5e6-96231b3b80d8
commit b9d13ac6e4228451c6fe54566064978597aabc1b
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 09:16:46 2009 +0000
llvm-mc: Make MCValue take const MCSymbol*s.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80078 91177308-0d34-0410-b5e6-96231b3b80d8
commit cb73cfe2496d5e70d8cc4c89e7de29373b348353
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 09:16:34 2009 +0000
llvm-mc: Make non-sensical max bytes to .align an error.
Also, warn about overflow in alignment values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80077 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3e64a6cc0e75cf654fd23ac9ffa1a9a1d3d911e9
Author: Andreas Neustifter <astifter@gmx.at>
Date: Wed Aug 26 09:05:21 2009 +0000
Changed std::cout to outs(), retaining formating.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80076 91177308-0d34-0410-b5e6-96231b3b80d8
commit 94060421ce73922e71c183fba0fda8bace7d0e2d
Author: Devang Patel <dpatel@apple.com>
Date: Wed Aug 26 05:01:18 2009 +0000
Revert 79977. It causes llvm-gcc bootstrap failures on some platforms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80073 91177308-0d34-0410-b5e6-96231b3b80d8
commit 66d02907de42fa311fb2b512e820277bb1a61e7c
Author: Chris Lattner <sabre@nondot.org>
Date: Wed Aug 26 05:00:16 2009 +0000
some mips and some sparc compilers apparently
predefine mips and sparc respectively. Just overrule them :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80072 91177308-0d34-0410-b5e6-96231b3b80d8
commit 202ced1e32f5a88a8c865e62ea10c88a712c3fab
Author: Venkatraman Govindaraju <venkatra@cs.wisc.edu>
Date: Wed Aug 26 04:50:17 2009 +0000
test commit
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80070 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3eb9a3f37ed8ee8e026d2dfebe6bae08df4e615d
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 04:28:45 2009 +0000
llvm-mc: Fix tests for python variations in int printing, sigh.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80069 91177308-0d34-0410-b5e6-96231b3b80d8
commit 53a9082d2e95f33980ef2b7f5104e0cc46d6342d
Author: Chris Lattner <sabre@nondot.org>
Date: Wed Aug 26 04:21:30 2009 +0000
fix some funky indentation
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80068 91177308-0d34-0410-b5e6-96231b3b80d8
commit 0f56d41709c27ec2f0637e19881fefd90e31c22b
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 04:13:32 2009 +0000
llvm-mc/Mach-O: Add section padding where needed (to align the next section).
Also, simplify some of Mach-O writer code which can now use section addresses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80067 91177308-0d34-0410-b5e6-96231b3b80d8
commit b3730b1a3de7fe37a660bd30d3d0d55bcea22d1d
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 02:48:04 2009 +0000
llvm-mc/Mach-O: Set addresses for symbols.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80065 91177308-0d34-0410-b5e6-96231b3b80d8
commit 7fd6b0fff74a7c9fbc054b3303fee1a8f22002b2
Author: Dale Johannesen <dalej@apple.com>
Date: Wed Aug 26 01:08:21 2009 +0000
Add an 'inline hint' attribute to represent source
code hints that it would be a good idea to inline
a function ("inline" keyword). No functional change
yet; FEs do not emit this and inliner does not use it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80063 91177308-0d34-0410-b5e6-96231b3b80d8
commit 2e1a5d0b91503b8d5ada9fe0b19567daca2f1c6f
Author: Devang Patel <dpatel@apple.com>
Date: Wed Aug 26 00:39:50 2009 +0000
Add isClosure() predicate. This is used to add DW_AT_APPLE_block attribute.
Patch by Caroline Tice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80061 91177308-0d34-0410-b5e6-96231b3b80d8
commit 6d294da8f845a8d611529759d194315b76b44a6e
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 00:18:21 2009 +0000
llvm-mc: Improve indirect symbol support (add the indirect index table).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80059 91177308-0d34-0410-b5e6-96231b3b80d8
commit 3b126fbc67c6279898f8ca0c31f233a3a56b31d9
Author: Dan Gohman <gohman@apple.com>
Date: Wed Aug 26 00:13:22 2009 +0000
Remove unused variables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80058 91177308-0d34-0410-b5e6-96231b3b80d8
commit bdd4dc67fb10d0f304bec21c924263f8444ae7a7
Author: Daniel Dunbar <daniel@zuster.org>
Date: Wed Aug 26 00:10:55 2009 +0000
llvm-mc: Add MCSection::isDefined()
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80057 91177308-0d34-0410-b5e6-96231b3b80d8
commit 917614663633aa0ff1bdf7208862e8b7e25dd911
Author: Dan Gohman <gohman@apple.com>
Date: Tue Aug 25 23:27:45 2009 +0000
Fix the InsertAtEnd form of ShuffleVectorInst constructor to use
the correct type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80050 91177308-0d34-0410-b5e6-96231b3b80d8
commit e6803b821738076b5b2299c1cd496be0d0042362
Author: Dan Gohman <gohman@apple.com>
Date: Tue Aug 25 23:17:54 2009 +0000
Eliminate the unused Context argument on one of the ICmpInst and FCmpInst
constructors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80049 91177308-0d34-0410-b5e6-96231b3b80d8
commit 4e46ac9407307942712236f8c91875ef323c182f
Author: Gabor Greif <ggreif@gmail.com>
Date: Tue Aug 25 23:02:21 2009 +0000
revert r78628 and r78803 as these are not needed any more
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80048 91177308-0d34-0410-b5e6-96231b3b80d8
commit 58d95377713fa32cbf129e19f4005f4863f9cdb3
Author: Scott Michel <scottm@aero.org>
Date: Tue Aug 25 22:37:34 2009 +0000
Updated i128 sext support for CellSPU backend, contributed by Ken Werner (IBM)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80042 91177308-0d34-0410-b5e6-96231b3b80d8
commit 91bf99a35153b00098633f214207c308c52acdcd
Author: Dan Gohman <gohman@apple.com>
Date: Tue Aug 25 22:29:08 2009 +0000
Use covariant return types for Instruction::clone, and eliminate
the forms of ExtractElementInst and InsertElementInst that are
equivalent to clone.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80041 91177308-0d34-0410-b5e6-96231b3b80d8
commit 97be9d37d93c38bc82950e0373cd3a8d1d2aa024
Author: Owen Anderson <resistor@mac.com>
Date: Tue Aug 25 22:27:22 2009 +0000
Get rid of this horrible "benign race" by exploiting ManagedStatic to initialize
the array on its first access.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80040 91177308-0d34-0410-b5e6-96231b3b80d8
commit ba4fe8b91352f65caaf2a30f234b5006afd1cf2b
Author: Dan Gohman <gohman@apple.com>
Date: Tue Aug 25 22:24:20 2009 +0000
This should use isIndenticalToWhenDefined.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80039 91177308-0d34-0410-b5e6-96231b3b80d8
commit fc00c4a2407c1b30a19fef9ec0a1ae00f7f7472d
Author: Dan Gohman <gohman@apple.com>
Date: Tue Aug 25 22:11:20 2009 +0000
Rename Instruction::isIdenticalTo to Instruction::isIdenticalToWhenDefined,
and introduce a new Instruction::isIdenticalTo which tests for full
identity, including the SubclassOptionalData flags. Also, fix the
Instruction::clone implementations to preserve the SubclassOptionalData
flags. Finally, teach several optimizations how to handle
SubclassOptionalData correctly, given these changes.
This fixes the counterintuitive behavior of isIdenticalTo not comparing
the full value, and clone not returning an identical clone, as well as
some subtle bugs that could be caused by these.
Thanks to Nick Lewycky for reporting this, and for an initial patch!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80038 91177308-0d34-0410-b5e6-96231b3b80d8
commit e73ff31d813cdc36e334404992c42bfef7842c95
Author: Bill Wendling <isanbard@gmail.com>
Date: Tue Aug 25 21:31:39 2009 +0000
Revert last patch. We need to put this into TargetLowering. There will be a lot
of EH stuff going into there, so we can wait to add them all then.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80036 91177308-0d34-0410-b5e6-96231b3b80d8
commit 12d46f5ea460e149882e39dc25c649580a161141
Author: Gabor Greif <ggreif@gmail.com>
Date: Tue Aug 25 21:25:22 2009 +0000
re-committing yesterday's r79938.
This time there is no additional include of llvm/Config/config.h
at all. Instead I use a hard-coded preprecessor symbol:
LLVM_COMPACTIFY_SENTINELS
(should this work on the self-hosting buildbot, then
cleanups come next)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80035 91177308-0d34-0410-b5e6-96231b3b80d8
commit b81243240cbfc573324c9760a77e6b1463955bab
Author: Daniel Dunbar <daniel@zuster.org>
Date: Tue Aug 25 21:10:45 2009 +0000
llvm-mc: Add statistic for number of fragments emitted by the assembler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80033 91177308-0d34-0410-b5e6-96231b3b80d8
commit 4f61e5051fa25f4abb928573db6ea52585748b93
Author: Bill Wendling <isanbard@gmail.com>
Date: Tue Aug 25 21:09:50 2009 +0000
Add the #include here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80032 91177308-0d34-0410-b5e6-96231b3b80d8
commit 4b90952a9dd2b26ef6dd359cb8e4f7139e40f864
Author: Chris Lattner <sabre@nondot.org>
Date: Tue Aug 25 21:01:56 2009 +0000
remove some dead lines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80031 91177308-0d34-0410-b5e6-96231b3b80d8
commit 538dfe54dd1c732208b2dbb00057b0a58cdeb61e
Author: Bill Wendling <isanbard@gmail.com>
Date: Tue Aug 25 21:01:42 2009 +0000
Comment formatting. Removing of unused #include and type forwarding.
OCD is fun!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80030 91177308-0d34-0410-b5e6-96231b3b80d8
commit f2db1075b5a1bf1ea8f2d2c618917651150b8a94
Author: Chris Lattner <sabre@nondot.org>
Date: Tue Aug 25 20:57:38 2009 +0000
convert to filecheck style
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80029 91177308-0d34-0410-b5e6-96231b3b80d8
commit 864504a5810fdfd23e1774de0b935dcdafb91645
Author: Chris Lattner <sabre@nondot.org>
Date: Tue Aug 25 20:49:04 2009 +0000
convert to filecheck
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80025 91177308-0d34-0410-b5e6-96231b3b80d8
commit e371d63e2a817eda5e3563eb574c99fa08df7e6d
Author: Bill Wendling <isanbard@gmail.com>
Date: Tue Aug 25 20:21:17 2009 +0000
Add a target asm info hook to specify that particular bits of data in the FDE
should be forced to 32-bits (.long) even on 64-bit architectures. Darwin wants
these bits to be 64-bits (.quad). However, other platforms may disagree.
This is just the info right now and is part of a work-in-progress which needs
this. We'll add the actual *use* of this soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80024 91177308-0d34-0410-b5e6-96231b3b80d8
commit b0b96906a0018edbadd9f4f3b17b48ec3c29838e
Author: Daniel Dunbar <daniel@zuster.org>
Date: Tue Aug 25 20:21:09 2009 +0000
EXIT STAGE LEFT: gccas, gccld
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80023 91177308-0d34-0410-b5e6-96231b3b80d8
commit 13808ef92db201ec027004b4fd8eb2db55c5aae4
Author: Sanjiv Gupta <sanjiv.gupta@microchip.com>
Date: Tue Aug 25 19:39:05 2009 +0000
Start refactoring PIC16 TargetObjectFile code. Eventually, all the stuff from
PIC16Section will move to MCSectionPIC16.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80021 91177308-0d34-0410-b5e6-96231b3b80d8
commit b1d423e0cccd3f78122a5e8c9e959c8569b23bb0
Author: Daniel Dunbar <daniel@zuster.org>
Date: Tue Aug 25 18:45:03 2009 +0000
Switch abi-isel.ll to FileCheck; it's not much faster, but it now tests a lot
more and is much nicer to the OS.
- Dan, please check. If there are parts of the test you think I should strip
out so it doesn't cause random failures let me know (there are still some PIC
label numbers in it, for example).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80019 91177308-0d34-0410-b5e6-96231b3b80d8
commit 1d99646fa9e8847b0ceb086e33a24ed707491684
Author: Dan Gohman <gohman@apple.com>
Date: Tue Aug 25 17:56:57 2009 +0000
Don't assume that two identical instructions that read from memory
will always return the same value. This isn't currently necessary,
since this code doesn't currently ever get called under circumstances
where it would matter, but it may some day.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80017 91177308-0d34-0410-b5e6-96231b3b80d8
commit 82d30b73d3a37de0ec7960a4e099ef9e255d4f11
Author: Bob Wilson <bob.wilson@apple.com>
Date: Tue Aug 25 17:52:39 2009 +0000
Remove some unused SDNode definitions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80015 91177308-0d34-0410-b5e6-96231b3b80d8
commit 5bba145cbd5935b442e6a197eda3477f5d1372a5
Author: Dan Gohman <gohman@apple.com>
Date: Tue Aug 25 17:49:57 2009 +0000
Teach ScalarEvolution about GlobalAliases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80014 91177308-0d34-0410-b5e6-96231b3b80d8
commit 1c17fd9fbdcfebe29c7ea59c2c7675e420aa49f5
Author: Dan Gohman <gohman@apple.com>
Date: Tue Aug 25 17:48:17 2009 +0000
Delete some unnecessary flushes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80013 91177308-0d34-0410-b5e6-96231b3b80d8
commit 814c2eaa0121afd0661d8a2b5f715fcb1174f0b5
Author: Dan Gohman <gohman@apple.com>
Date: Tue Aug 25 17:47:44 2009 +0000
Use X86II::MO_NO_FLAG.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80012 91177308-0d34-0410-b5e6-96231b3b80d8
commit 316062a4d193609d98e80e64389fc2094ad8c515
Author: Bob Wilson <bob.wilson@apple.com>
Date: Tue Aug 25 17:46:06 2009 +0000
Expose the instruction contraint string as an argument to the NLdSt class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80011 91177308-0d34-0410-b5e6-96231b3b80d8
commit 208278cfa708aa6e5fcca6d1b92ee780beb72a8c
Author: Dan Gohman <gohman@apple.com>
Date: Tue Aug 25 17:42:10 2009 +0000
Special-case static allocas in IndVarSimplify's loop invariant
sinking code, since they are special. If the loop preheader happens
to be the entry block of a function, don't sink static allocas
out of it. This fixes PR4775.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80010 91177308-0d34-0410-b5e6-96231b3b80d8
commit 36ed6c0368d77188063d1594e54c52df1438ae87
Author: Owen Anderson <resistor@mac.com>
Date: Tue Aug 25 17:42:07 2009 +0000
Comment-ify.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80009 91177308-0d34-0410-b5e6-96231b3b80d8
commit 845a722eb435c2a9c0528b13a472e595340b6dd8
Author: Owen Anderson <resistor@mac.com>
Date: Tue Aug 25 17:35:37 2009 +0000
Switch to SmallVector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80007 91177308-0d34-0410-b5e6-96231b3b80d8
commit 2845c6f885c8c7615610ab8494f7535a8f67334c
Author: Owen Anderson <resistor@mac.com>
Date: Tue Aug 25 17:26:32 2009 +0000
Pull out this predicate loop into a helper function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80006 91177308-0d34-0410-b5e6-96231b3b80d8
commit a9c16fe7d4d2b61191b362a5d073bdc95c123c0f
Author: David Goodwin <david_goodwin@apple.com>
Date: Tue Aug 25 17:03:05 2009 +0000
Fixup register kills after scheduling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80002 91177308-0d34-0410-b5e6-96231b3b80d8
commit 9518d88d270c05fb576604fc813405de177e2e34
Author: Anton Korobeynikov <asl@math.spbu.ru>
Date: Tue Aug 25 17:00:23 2009 +0000
Provide dynamic_stackalloc lowering for MSP430.
This fixes PR4769
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80001 91177308-0d34-0410-b5e6-96231b3b80d8
commit b802d676875f2df286887be83419649770dd8580
Author: Edwin Török <edwintorok@gmail.com>
Date: Tue Aug 25 16:53:15 2009 +0000
Remove target triple from this test, it fails on x86-64 with
--enable-targets=host-only otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80000 91177308-0d34-0410-b5e6-96231b3b80d8
commit e577ff861e934b98cb950a0b0d32d0a9a1dce8b1
Author: Dan Gohman <gohman@apple.com>
Date: Tue Aug 25 16:00:35 2009 +0000
Allocate the basic types inside the LLVMContextImpl instance,
rather than separately with new. Move the members above the
TypeMap members to avoid destruction order issues. This fixes
a leak of these objects, and eliminates an extra level of
indirection in Type::getInt32Ty and friends.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79997 91177308-0d34-0410-b5e6-96231b3b80d8
commit 87489cff37dde33a9dbb37fbfbad46ce2f70c8af
Author: Dan Gohman <gohman@apple.com>
Date: Tue Aug 25 15:54:01 2009 +0000
Update documentation for the -f change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79996 91177308-0d34-0410-b5e6-96231b3b80d8
commit a0e89b2e414df522132636eb256ecbcc2d01a4e8
Author: Dan Gohman <gohman@apple.com>
Date: Tue Aug 25 15:45:44 2009 +0000
Fix a few typos from the removal of -f.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79994 91177308-0d34-0410-b5e6-96231b3b80d8
commit 2d65d35d9233277aee7c8a6d3643740e3ed29f0b
Author: Dan Gohman <gohman@apple.com>
Date: Tue Aug 25 15:38:29 2009 +0000
Remove obsolete -f flags.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79992 91177308-0d34-0410-b5e6-96231b3b80d8
commit 176426d2102142aaa0bf19aca55f528ceb873329
Author: Dan Gohman <gohman@apple.com>
Date: Tue Aug 25 15:34:52 2009 +0000
Make LLVM command-line tools overwrite their output files without -f.
This is conventional command-line tool behavior. -f now just means
"enable binary output on terminals".
Add a -f option to llvm-extract and llvm-link, for consistency.
Remove F_Force from raw_fd_ostream and enable overwriting and
truncating by default. Introduce an F_Excl flag to permit users to
enable a failure when the file already exists. This flag is
currently unused.
Update Makefiles and documentation accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79990 91177308-0d34-0410-b5e6-96231b3b80d8
commit 8c949d7c548ed4ec883a2c8bd922607be2563f5a
Author: Andreas Neustifter <astifter@gmx.at>
Date: Tue Aug 25 12:53:27 2009 +0000
Read profile files as binary as proposed in
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-August/025020.html.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79983 91177308-0d34-0410-b5e6-96231b3b80d8
commit 9112f5f6755a85f10036ff20741fc264622dc14a
Author: Xerxes Ranby <xerxes@zafena.se>
Date: Tue Aug 25 10:12:55 2009 +0000
Fix PR4772 ARM JIT.GlobalInFuction unittest by explicitly initialize MMI
to 0 during JITEmitter constructor.
Modified:
lib/ExecutionEngine/JIT/JITEmitter.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79982 91177308-0d34-0410-b5e6-96231b3b80d8
commit a75796301ee17e60daea754e30a035a53891650d
Author: Bill Wendling <isanbard@gmail.com>
Date: Tue Aug 25 08:08:33 2009 +0000
- Rename EmitCommonInformationEntry to EmitCIE.
- Rename EmitFunctionDescriptionEntry to EmitFDE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79981 91177308-0d34-0410-b5e6-96231b3b80d8
commit 57b83c78f56324e3a8ff636b311235f6f2350b4e
Author: Devang Patel <dpatel@apple.com>
Date: Tue Aug 25 05:24:07 2009 +0000
Update DebugInfo interface to use metadata, instead of special named llvm.dbg.... global variables, to encode debugging information in llvm IR. This is mostly a mechanical change that tests metadata support very well.
This change speeds up llvm-gcc by more then 6% at "-O0 -g" (measured by compiling InstructionCombining.cpp!)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79977 91177308-0d34-0410-b5e6-96231b3b80d8
commit bcc93309ca3632b3cd2b45f265a534256be7589a
Author: Bill Wendling <isanbard@gmail.com>
Date: Tue Aug 25 02:32:05 2009 +0000
- Emit new line after each FDE.
- Fix comment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79971 91177308-0d34-0410-b5e6-96231b3b80d8
commit 4767b24840250630c47fee8be2a6aef07f19d30a
Author: Bill Wendling <isanbard@gmail.com>
Date: Tue Aug 25 02:27:42 2009 +0000
Rename functions to something more descriptive. At the very least mention the
CIE and FDE in their names.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79969 91177308-0d34-0410-b5e6-96231b3b80d8
commit 30d4d765dfc6d01bc4c1d6934582050106bcceba
Author: Dale Johannesen <dalej@apple.com>
Date: Tue Aug 25 01:13:58 2009 +0000
Allow multiple occurrences of -inline-threshold on
the command line. This gives llvm-gcc developers
a way to control inlining (documented as "not intended
for end users").
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79966 91177308-0d34-0410-b5e6-96231b3b80d8
commit 06b990c5b3f32505188e52be1b70b38290f81b83
Author: Owen Anderson <resistor@mac.com>
Date: Tue Aug 25 00:54:39 2009 +0000
Handle a corner case when extracing code regions where one of the immediate successor
of an extracted block contains a PHI using a value defined in the extracted region.
With this patch, the partial inliner now passes MultiSource/Applications.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79963 91177308-0d34-0410-b5e6-96231b3b80d8
commit f1f04ecf6e5af3aa7c4c59077486c9cb29df20ea
Author: Dale Johannesen <dalej@apple.com>
Date: Tue Aug 25 00:16:14 2009 +0000
Fix PR 4751, another difficulty with %a modifier on x86.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79961 91177308-0d34-0410-b5e6-96231b3b80d8
commit 09220a24f7845a078fb41c61ee909eed6c94a255
Author: Bill Wendling <isanbard@gmail.com>
Date: Tue Aug 25 00:05:04 2009 +0000
--- Reverse-merging r79938 into '.':
U include/llvm/BasicBlock.h
U include/llvm/ADT/ilist_node.h
U include/llvm/ADT/ilist.h
U include/llvm/CodeGen/SelectionDAG.h
U include/llvm/CodeGen/MachineFunction.h
U include/llvm/CodeGen/MachineBasicBlock.h
U include/llvm/Function.h
Revert r79938. It was causing self-hosting build failures.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79960 91177308-0d34-0410-b5e6-96231b3b80d8
commit f2942e63abf0b485e88c21a9fc96bfb13754ed41
Author: Oscar Fuentes <ofv@wanadoo.es>
Date: Tue Aug 25 00:02:29 2009 +0000
CMake: updated list of source files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79959 91177308-0d34-0410-b5e6-96231b3b80d8
commit 399ece6621d316d7378e5fc13bd030e5572f03ce
Author: Scott Michel <scottm@aero.org>
Date: Mon Aug 24 23:57:35 2009 +0000
- Remove SelectSEXTi128 from SPUISelDAGToDAG.cpp, evidently, this is redundant
code, according to Anton (I'm not totally convinced, but we can always
resurrect patches if we need to do so.)
- Start moving CellSPU's tests to prefer FileCheck.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79958 91177308-0d34-0410-b5e6-96231b3b80d8
commit 27dad5a41e0b0fa8fd5cba2e6f5dd70b82689e76
Author: Owen Anderson <resistor@mac.com>
Date: Mon Aug 24 23:32:14 2009 +0000
When extracting SEME regions of code, the extractor needs to update the dominator tree for split return blocks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79957 91177308-0d34-0410-b5e6-96231b3b80d8
commit 316e6fb92b997dfa4db655a371d5699cbcac0473
Author: Scott Michel <scottm@aero.org>
Date: Mon Aug 24 22:49:22 2009 +0000
Prefer 'FileCheck' over 'grep'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79953 91177308-0d34-0410-b5e6-96231b3b80d8
commit 36173e27ebfe4da907c17f2b507a9df3415a3aad
Author: Scott Michel <scottm@aero.org>
Date: Mon Aug 24 22:28:53 2009 +0000
128-bit sign extension and vector shift cleanups, contributed by Ken Werner
(IBM).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79949 91177308-0d34-0410-b5e6-96231b3b80d8
commit 73ab81726b384015ac9bfe7f734fc13b93297c4c
Author: Scott Michel <scottm@aero.org>
Date: Mon Aug 24 21:53:27 2009 +0000
Initialize ShufBytes, as gcc 4.4 can't detect that the entire array is
initialized and a warning about a potentially unintialized variable is
generated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79946 91177308-0d34-0410-b5e6-96231b3b80d8
commit af26e32df3f129ac906a45c4527b5ee3641cb22d
Author: Andreas Neustifter <astifter@gmx.at>
Date: Mon Aug 24 21:41:37 2009 +0000
Add llvm_start_edge_profiling to exported symbols for libprofile_rt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79944 91177308-0d34-0410-b5e6-96231b3b80d8
commit 92b39ace140de279245e80d0465528933787c7e4
Author: Andreas Neustifter <astifter@gmx.at>
Date: Mon Aug 24 21:37:48 2009 +0000
This patch cleans up the ProfileInfo by
*) introducing new data type and export function of edge info for whole function (preparation for next patch).
*) renaming variables to make clear distinction between data and containers that contain this data.
*) updated comments and whitespaces.
*) made ProfileInfo::MissingValue a double (as it should be...).
(Discussed at http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090817/084955.html.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79940 91177308-0d34-0410-b5e6-96231b3b80d8
commit c19dfb9d25347b815512bba5eb64052708e4c183
Author: Gabor Greif <ggreif@gmail.com>
Date: Mon Aug 24 21:34:17 2009 +0000
Resubmit an earlier patch of mine:
reduce the size of relevant "ghostly" sentinels
by a pointer.
This attempt now makes the compactification dependent
on the configure variable LLVM_COMPACT_SENTINELS
and should not cause any bootstrap failures for
llvm-gcc any more.
Please note that this is not yet the final version,
and (as settled with Chris) I shall take out the
autofoo/cmake portions in the next days.
This will also lose the assertability on sentinel
dereferencing and operator++, but that seems
an acceptable price to pay for the simplified
build logic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79938 91177308-0d34-0410-b5e6-96231b3b80d8
commit b2f99910fba8818270e41e75f4b127d82a2082a6
Author: Bob Wilson <bob.wilson@apple.com>
Date: Mon Aug 24 21:17:17 2009 +0000
Fix a typo. Somehow I thought this had passed before, but I guess not.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79937 91177308-0d34-0410-b5e6-96231b3b80d8
commit f5c686b114bf6ac6b3137f96bc59ffb2e8e20de6
Author: Gabor Greif <ggreif@gmail.com>
Date: Mon Aug 24 21:00:10 2009 +0000
prune ignores: AutoGenerated.inc is no more
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79936 91177308-0d34-0410-b5e6-96231b3b80d8
commit cacea03dbaca34b44783243898ef2274bd71e72e
Author: Bob Wilson <bob.wilson@apple.com>
Date: Mon Aug 24 20:33:47 2009 +0000
Convert slow test to use FileCheck.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79935 91177308-0d34-0410-b5e6-96231b3b80d8
commit 8551a303173101cf595dc35200eea7da37e769d4
Author: Daniel Dunbar <daniel@zuster.org>
Date: Mon Aug 24 20:08:27 2009 +0000
Convert two gratuitous abuses of poor helpless CPU cycles to FileCheck.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79933 91177308-0d34-0410-b5e6-96231b3b80d8
commit b9640223f05f0257603a0138c1ea8cb59c7f5acc
Author: Dale Johannesen <dalej@apple.com>
Date: Mon Aug 24 17:51:19 2009 +0000
Split test into 3.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79926 91177308-0d34-0410-b5e6-96231b3b80d8
commit a0151d0e9f948b39e55944b5cad64fb33732af25
Author: Daniel Dunbar <daniel@zuster.org>
Date: Mon Aug 24 11:56:58 2009 +0000
llvm-mc/Mach-O: Preliminary support for indirect symbols.
- The indirect table itself isn't being filled in yet.
- This isn't factored properly and is rather FIXMEd, but at the moment I'm more
focused on figuring out what it needs to do.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79910 91177308-0d34-0410-b5e6-96231b3b80d8
commit b69f053e0d5af3463d1bbf2101e5c1431cca6fee
Author: Duncan Sands <baldrick@free.fr>
Date: Mon Aug 24 10:59:01 2009 +0000
Fix the build when using gcc-4.4 on linux. Header needed
for stderr and fprintf.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79909 91177308-0d34-0410-b5e6-96231b3b80d8
2125 lines
89 KiB
HTML
2125 lines
89 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
|
|
"http://www.w3.org/TR/html4/strict.dtd">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="content-type" content="text/html; charset=utf-8">
|
|
<title>The LLVM Target-Independent Code Generator</title>
|
|
<link rel="stylesheet" href="llvm.css" type="text/css">
|
|
</head>
|
|
<body>
|
|
|
|
<div class="doc_title">
|
|
The LLVM Target-Independent Code Generator
|
|
</div>
|
|
|
|
<ol>
|
|
<li><a href="#introduction">Introduction</a>
|
|
<ul>
|
|
<li><a href="#required">Required components in the code generator</a></li>
|
|
<li><a href="#high-level-design">The high-level design of the code
|
|
generator</a></li>
|
|
<li><a href="#tablegen">Using TableGen for target description</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#targetdesc">Target description classes</a>
|
|
<ul>
|
|
<li><a href="#targetmachine">The <tt>TargetMachine</tt> class</a></li>
|
|
<li><a href="#targetdata">The <tt>TargetData</tt> class</a></li>
|
|
<li><a href="#targetlowering">The <tt>TargetLowering</tt> class</a></li>
|
|
<li><a href="#targetregisterinfo">The <tt>TargetRegisterInfo</tt> class</a></li>
|
|
<li><a href="#targetinstrinfo">The <tt>TargetInstrInfo</tt> class</a></li>
|
|
<li><a href="#targetframeinfo">The <tt>TargetFrameInfo</tt> class</a></li>
|
|
<li><a href="#targetsubtarget">The <tt>TargetSubtarget</tt> class</a></li>
|
|
<li><a href="#targetjitinfo">The <tt>TargetJITInfo</tt> class</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#codegendesc">Machine code description classes</a>
|
|
<ul>
|
|
<li><a href="#machineinstr">The <tt>MachineInstr</tt> class</a></li>
|
|
<li><a href="#machinebasicblock">The <tt>MachineBasicBlock</tt>
|
|
class</a></li>
|
|
<li><a href="#machinefunction">The <tt>MachineFunction</tt> class</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#codegenalgs">Target-independent code generation algorithms</a>
|
|
<ul>
|
|
<li><a href="#instselect">Instruction Selection</a>
|
|
<ul>
|
|
<li><a href="#selectiondag_intro">Introduction to SelectionDAGs</a></li>
|
|
<li><a href="#selectiondag_process">SelectionDAG Code Generation
|
|
Process</a></li>
|
|
<li><a href="#selectiondag_build">Initial SelectionDAG
|
|
Construction</a></li>
|
|
<li><a href="#selectiondag_legalize_types">SelectionDAG LegalizeTypes Phase</a></li>
|
|
<li><a href="#selectiondag_legalize">SelectionDAG Legalize Phase</a></li>
|
|
<li><a href="#selectiondag_optimize">SelectionDAG Optimization
|
|
Phase: the DAG Combiner</a></li>
|
|
<li><a href="#selectiondag_select">SelectionDAG Select Phase</a></li>
|
|
<li><a href="#selectiondag_sched">SelectionDAG Scheduling and Formation
|
|
Phase</a></li>
|
|
<li><a href="#selectiondag_future">Future directions for the
|
|
SelectionDAG</a></li>
|
|
</ul></li>
|
|
<li><a href="#liveintervals">Live Intervals</a>
|
|
<ul>
|
|
<li><a href="#livevariable_analysis">Live Variable Analysis</a></li>
|
|
<li><a href="#liveintervals_analysis">Live Intervals Analysis</a></li>
|
|
</ul></li>
|
|
<li><a href="#regalloc">Register Allocation</a>
|
|
<ul>
|
|
<li><a href="#regAlloc_represent">How registers are represented in
|
|
LLVM</a></li>
|
|
<li><a href="#regAlloc_howTo">Mapping virtual registers to physical
|
|
registers</a></li>
|
|
<li><a href="#regAlloc_twoAddr">Handling two address instructions</a></li>
|
|
<li><a href="#regAlloc_ssaDecon">The SSA deconstruction phase</a></li>
|
|
<li><a href="#regAlloc_fold">Instruction folding</a></li>
|
|
<li><a href="#regAlloc_builtIn">Built in register allocators</a></li>
|
|
</ul></li>
|
|
<li><a href="#codeemit">Code Emission</a>
|
|
<ul>
|
|
<li><a href="#codeemit_asm">Generating Assembly Code</a></li>
|
|
<li><a href="#codeemit_bin">Generating Binary Machine Code</a></li>
|
|
</ul></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#targetimpls">Target-specific Implementation Notes</a>
|
|
<ul>
|
|
<li><a href="#tailcallopt">Tail call optimization</a></li>
|
|
<li><a href="#x86">The X86 backend</a></li>
|
|
<li><a href="#ppc">The PowerPC backend</a>
|
|
<ul>
|
|
<li><a href="#ppc_abi">LLVM PowerPC ABI</a></li>
|
|
<li><a href="#ppc_frame">Frame Layout</a></li>
|
|
<li><a href="#ppc_prolog">Prolog/Epilog</a></li>
|
|
<li><a href="#ppc_dynamic">Dynamic Allocation</a></li>
|
|
</ul></li>
|
|
</ul></li>
|
|
|
|
</ol>
|
|
|
|
<div class="doc_author">
|
|
<p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a>,
|
|
<a href="mailto:isanbard@gmail.com">Bill Wendling</a>,
|
|
<a href="mailto:pronesto@gmail.com">Fernando Magno Quintao
|
|
Pereira</a> and
|
|
<a href="mailto:jlaskey@mac.com">Jim Laskey</a></p>
|
|
</div>
|
|
|
|
<div class="doc_warning">
|
|
<p>Warning: This is a work in progress.</p>
|
|
</div>
|
|
|
|
<!-- *********************************************************************** -->
|
|
<div class="doc_section">
|
|
<a name="introduction">Introduction</a>
|
|
</div>
|
|
<!-- *********************************************************************** -->
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The LLVM target-independent code generator is a framework that provides a
|
|
suite of reusable components for translating the LLVM internal representation
|
|
to the machine code for a specified target—either in assembly form
|
|
(suitable for a static compiler) or in binary machine code format (usable for
|
|
a JIT compiler). The LLVM target-independent code generator consists of five
|
|
main components:</p>
|
|
|
|
<ol>
|
|
<li><a href="#targetdesc">Abstract target description</a> interfaces which
|
|
capture important properties about various aspects of the machine,
|
|
independently of how they will be used. These interfaces are defined in
|
|
<tt>include/llvm/Target/</tt>.</li>
|
|
|
|
<li>Classes used to represent the <a href="#codegendesc">machine code</a>
|
|
being generated for a target. These classes are intended to be abstract
|
|
enough to represent the machine code for <i>any</i> target machine. These
|
|
classes are defined in <tt>include/llvm/CodeGen/</tt>.</li>
|
|
|
|
<li><a href="#codegenalgs">Target-independent algorithms</a> used to implement
|
|
various phases of native code generation (register allocation, scheduling,
|
|
stack frame representation, etc). This code lives
|
|
in <tt>lib/CodeGen/</tt>.</li>
|
|
|
|
<li><a href="#targetimpls">Implementations of the abstract target description
|
|
interfaces</a> for particular targets. These machine descriptions make
|
|
use of the components provided by LLVM, and can optionally provide custom
|
|
target-specific passes, to build complete code generators for a specific
|
|
target. Target descriptions live in <tt>lib/Target/</tt>.</li>
|
|
|
|
<li><a href="#jit">The target-independent JIT components</a>. The LLVM JIT is
|
|
completely target independent (it uses the <tt>TargetJITInfo</tt>
|
|
structure to interface for target-specific issues. The code for the
|
|
target-independent JIT lives in <tt>lib/ExecutionEngine/JIT</tt>.</li>
|
|
</ol>
|
|
|
|
<p>Depending on which part of the code generator you are interested in working
|
|
on, different pieces of this will be useful to you. In any case, you should
|
|
be familiar with the <a href="#targetdesc">target description</a>
|
|
and <a href="#codegendesc">machine code representation</a> classes. If you
|
|
want to add a backend for a new target, you will need
|
|
to <a href="#targetimpls">implement the target description</a> classes for
|
|
your new target and understand the <a href="LangRef.html">LLVM code
|
|
representation</a>. If you are interested in implementing a
|
|
new <a href="#codegenalgs">code generation algorithm</a>, it should only
|
|
depend on the target-description and machine code representation classes,
|
|
ensuring that it is portable.</p>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="required">Required components in the code generator</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The two pieces of the LLVM code generator are the high-level interface to the
|
|
code generator and the set of reusable components that can be used to build
|
|
target-specific backends. The two most important interfaces
|
|
(<a href="#targetmachine"><tt>TargetMachine</tt></a>
|
|
and <a href="#targetdata"><tt>TargetData</tt></a>) are the only ones that are
|
|
required to be defined for a backend to fit into the LLVM system, but the
|
|
others must be defined if the reusable code generator components are going to
|
|
be used.</p>
|
|
|
|
<p>This design has two important implications. The first is that LLVM can
|
|
support completely non-traditional code generation targets. For example, the
|
|
C backend does not require register allocation, instruction selection, or any
|
|
of the other standard components provided by the system. As such, it only
|
|
implements these two interfaces, and does its own thing. Another example of
|
|
a code generator like this is a (purely hypothetical) backend that converts
|
|
LLVM to the GCC RTL form and uses GCC to emit machine code for a target.</p>
|
|
|
|
<p>This design also implies that it is possible to design and implement
|
|
radically different code generators in the LLVM system that do not make use
|
|
of any of the built-in components. Doing so is not recommended at all, but
|
|
could be required for radically different targets that do not fit into the
|
|
LLVM machine description model: FPGAs for example.</p>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="high-level-design">The high-level design of the code generator</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The LLVM target-independent code generator is designed to support efficient
|
|
and quality code generation for standard register-based microprocessors.
|
|
Code generation in this model is divided into the following stages:</p>
|
|
|
|
<ol>
|
|
<li><b><a href="#instselect">Instruction Selection</a></b> — This phase
|
|
determines an efficient way to express the input LLVM code in the target
|
|
instruction set. This stage produces the initial code for the program in
|
|
the target instruction set, then makes use of virtual registers in SSA
|
|
form and physical registers that represent any required register
|
|
assignments due to target constraints or calling conventions. This step
|
|
turns the LLVM code into a DAG of target instructions.</li>
|
|
|
|
<li><b><a href="#selectiondag_sched">Scheduling and Formation</a></b> —
|
|
This phase takes the DAG of target instructions produced by the
|
|
instruction selection phase, determines an ordering of the instructions,
|
|
then emits the instructions
|
|
as <tt><a href="#machineinstr">MachineInstr</a></tt>s with that ordering.
|
|
Note that we describe this in the <a href="#instselect">instruction
|
|
selection section</a> because it operates on
|
|
a <a href="#selectiondag_intro">SelectionDAG</a>.</li>
|
|
|
|
<li><b><a href="#ssamco">SSA-based Machine Code Optimizations</a></b> —
|
|
This optional stage consists of a series of machine-code optimizations
|
|
that operate on the SSA-form produced by the instruction selector.
|
|
Optimizations like modulo-scheduling or peephole optimization work
|
|
here.</li>
|
|
|
|
<li><b><a href="#regalloc">Register Allocation</a></b> — The target code
|
|
is transformed from an infinite virtual register file in SSA form to the
|
|
concrete register file used by the target. This phase introduces spill
|
|
code and eliminates all virtual register references from the program.</li>
|
|
|
|
<li><b><a href="#proepicode">Prolog/Epilog Code Insertion</a></b> — Once
|
|
the machine code has been generated for the function and the amount of
|
|
stack space required is known (used for LLVM alloca's and spill slots),
|
|
the prolog and epilog code for the function can be inserted and "abstract
|
|
stack location references" can be eliminated. This stage is responsible
|
|
for implementing optimizations like frame-pointer elimination and stack
|
|
packing.</li>
|
|
|
|
<li><b><a href="#latemco">Late Machine Code Optimizations</a></b> —
|
|
Optimizations that operate on "final" machine code can go here, such as
|
|
spill code scheduling and peephole optimizations.</li>
|
|
|
|
<li><b><a href="#codeemit">Code Emission</a></b> — The final stage
|
|
actually puts out the code for the current function, either in the target
|
|
assembler format or in machine code.</li>
|
|
</ol>
|
|
|
|
<p>The code generator is based on the assumption that the instruction selector
|
|
will use an optimal pattern matching selector to create high-quality
|
|
sequences of native instructions. Alternative code generator designs based
|
|
on pattern expansion and aggressive iterative peephole optimization are much
|
|
slower. This design permits efficient compilation (important for JIT
|
|
environments) and aggressive optimization (used when generating code offline)
|
|
by allowing components of varying levels of sophistication to be used for any
|
|
step of compilation.</p>
|
|
|
|
<p>In addition to these stages, target implementations can insert arbitrary
|
|
target-specific passes into the flow. For example, the X86 target uses a
|
|
special pass to handle the 80x87 floating point stack architecture. Other
|
|
targets with unusual requirements can be supported with custom passes as
|
|
needed.</p>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="tablegen">Using TableGen for target description</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The target description classes require a detailed description of the target
|
|
architecture. These target descriptions often have a large amount of common
|
|
information (e.g., an <tt>add</tt> instruction is almost identical to a
|
|
<tt>sub</tt> instruction). In order to allow the maximum amount of
|
|
commonality to be factored out, the LLVM code generator uses
|
|
the <a href="TableGenFundamentals.html">TableGen</a> tool to describe big
|
|
chunks of the target machine, which allows the use of domain-specific and
|
|
target-specific abstractions to reduce the amount of repetition.</p>
|
|
|
|
<p>As LLVM continues to be developed and refined, we plan to move more and more
|
|
of the target description to the <tt>.td</tt> form. Doing so gives us a
|
|
number of advantages. The most important is that it makes it easier to port
|
|
LLVM because it reduces the amount of C++ code that has to be written, and
|
|
the surface area of the code generator that needs to be understood before
|
|
someone can get something working. Second, it makes it easier to change
|
|
things. In particular, if tables and other things are all emitted
|
|
by <tt>tblgen</tt>, we only need a change in one place (<tt>tblgen</tt>) to
|
|
update all of the targets to a new interface.</p>
|
|
|
|
</div>
|
|
|
|
<!-- *********************************************************************** -->
|
|
<div class="doc_section">
|
|
<a name="targetdesc">Target description classes</a>
|
|
</div>
|
|
<!-- *********************************************************************** -->
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The LLVM target description classes (located in the
|
|
<tt>include/llvm/Target</tt> directory) provide an abstract description of
|
|
the target machine independent of any particular client. These classes are
|
|
designed to capture the <i>abstract</i> properties of the target (such as the
|
|
instructions and registers it has), and do not incorporate any particular
|
|
pieces of code generation algorithms.</p>
|
|
|
|
<p>All of the target description classes (except the
|
|
<tt><a href="#targetdata">TargetData</a></tt> class) are designed to be
|
|
subclassed by the concrete target implementation, and have virtual methods
|
|
implemented. To get to these implementations, the
|
|
<tt><a href="#targetmachine">TargetMachine</a></tt> class provides accessors
|
|
that should be implemented by the target.</p>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="targetmachine">The <tt>TargetMachine</tt> class</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The <tt>TargetMachine</tt> class provides virtual methods that are used to
|
|
access the target-specific implementations of the various target description
|
|
classes via the <tt>get*Info</tt> methods (<tt>getInstrInfo</tt>,
|
|
<tt>getRegisterInfo</tt>, <tt>getFrameInfo</tt>, etc.). This class is
|
|
designed to be specialized by a concrete target implementation
|
|
(e.g., <tt>X86TargetMachine</tt>) which implements the various virtual
|
|
methods. The only required target description class is
|
|
the <a href="#targetdata"><tt>TargetData</tt></a> class, but if the code
|
|
generator components are to be used, the other interfaces should be
|
|
implemented as well.</p>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="targetdata">The <tt>TargetData</tt> class</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The <tt>TargetData</tt> class is the only required target description class,
|
|
and it is the only class that is not extensible (you cannot derived a new
|
|
class from it). <tt>TargetData</tt> specifies information about how the
|
|
target lays out memory for structures, the alignment requirements for various
|
|
data types, the size of pointers in the target, and whether the target is
|
|
little-endian or big-endian.</p>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="targetlowering">The <tt>TargetLowering</tt> class</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The <tt>TargetLowering</tt> class is used by SelectionDAG based instruction
|
|
selectors primarily to describe how LLVM code should be lowered to
|
|
SelectionDAG operations. Among other things, this class indicates:</p>
|
|
|
|
<ul>
|
|
<li>an initial register class to use for various <tt>ValueType</tt>s,</li>
|
|
|
|
<li>which operations are natively supported by the target machine,</li>
|
|
|
|
<li>the return type of <tt>setcc</tt> operations,</li>
|
|
|
|
<li>the type to use for shift amounts, and</li>
|
|
|
|
<li>various high-level characteristics, like whether it is profitable to turn
|
|
division by a constant into a multiplication sequence</li>
|
|
</ul>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="targetregisterinfo">The <tt>TargetRegisterInfo</tt> class</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The <tt>TargetRegisterInfo</tt> class is used to describe the register file
|
|
of the target and any interactions between the registers.</p>
|
|
|
|
<p>Registers in the code generator are represented in the code generator by
|
|
unsigned integers. Physical registers (those that actually exist in the
|
|
target description) are unique small numbers, and virtual registers are
|
|
generally large. Note that register #0 is reserved as a flag value.</p>
|
|
|
|
<p>Each register in the processor description has an associated
|
|
<tt>TargetRegisterDesc</tt> entry, which provides a textual name for the
|
|
register (used for assembly output and debugging dumps) and a set of aliases
|
|
(used to indicate whether one register overlaps with another).</p>
|
|
|
|
<p>In addition to the per-register description, the <tt>TargetRegisterInfo</tt>
|
|
class exposes a set of processor specific register classes (instances of the
|
|
<tt>TargetRegisterClass</tt> class). Each register class contains sets of
|
|
registers that have the same properties (for example, they are all 32-bit
|
|
integer registers). Each SSA virtual register created by the instruction
|
|
selector has an associated register class. When the register allocator runs,
|
|
it replaces virtual registers with a physical register in the set.</p>
|
|
|
|
<p>The target-specific implementations of these classes is auto-generated from
|
|
a <a href="TableGenFundamentals.html">TableGen</a> description of the
|
|
register file.</p>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="targetinstrinfo">The <tt>TargetInstrInfo</tt> class</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The <tt>TargetInstrInfo</tt> class is used to describe the machine
|
|
instructions supported by the target. It is essentially an array of
|
|
<tt>TargetInstrDescriptor</tt> objects, each of which describes one
|
|
instruction the target supports. Descriptors define things like the mnemonic
|
|
for the opcode, the number of operands, the list of implicit register uses
|
|
and defs, whether the instruction has certain target-independent properties
|
|
(accesses memory, is commutable, etc), and holds any target-specific
|
|
flags.</p>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="targetframeinfo">The <tt>TargetFrameInfo</tt> class</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The <tt>TargetFrameInfo</tt> class is used to provide information about the
|
|
stack frame layout of the target. It holds the direction of stack growth, the
|
|
known stack alignment on entry to each function, and the offset to the local
|
|
area. The offset to the local area is the offset from the stack pointer on
|
|
function entry to the first location where function data (local variables,
|
|
spill locations) can be stored.</p>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="targetsubtarget">The <tt>TargetSubtarget</tt> class</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The <tt>TargetSubtarget</tt> class is used to provide information about the
|
|
specific chip set being targeted. A sub-target informs code generation of
|
|
which instructions are supported, instruction latencies and instruction
|
|
execution itinerary; i.e., which processing units are used, in what order,
|
|
and for how long.</p>
|
|
|
|
</div>
|
|
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="targetjitinfo">The <tt>TargetJITInfo</tt> class</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The <tt>TargetJITInfo</tt> class exposes an abstract interface used by the
|
|
Just-In-Time code generator to perform target-specific activities, such as
|
|
emitting stubs. If a <tt>TargetMachine</tt> supports JIT code generation, it
|
|
should provide one of these objects through the <tt>getJITInfo</tt>
|
|
method.</p>
|
|
|
|
</div>
|
|
|
|
<!-- *********************************************************************** -->
|
|
<div class="doc_section">
|
|
<a name="codegendesc">Machine code description classes</a>
|
|
</div>
|
|
<!-- *********************************************************************** -->
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>At the high-level, LLVM code is translated to a machine specific
|
|
representation formed out of
|
|
<a href="#machinefunction"><tt>MachineFunction</tt></a>,
|
|
<a href="#machinebasicblock"><tt>MachineBasicBlock</tt></a>,
|
|
and <a href="#machineinstr"><tt>MachineInstr</tt></a> instances (defined
|
|
in <tt>include/llvm/CodeGen</tt>). This representation is completely target
|
|
agnostic, representing instructions in their most abstract form: an opcode
|
|
and a series of operands. This representation is designed to support both an
|
|
SSA representation for machine code, as well as a register allocated, non-SSA
|
|
form.</p>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="machineinstr">The <tt>MachineInstr</tt> class</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>Target machine instructions are represented as instances of the
|
|
<tt>MachineInstr</tt> class. This class is an extremely abstract way of
|
|
representing machine instructions. In particular, it only keeps track of an
|
|
opcode number and a set of operands.</p>
|
|
|
|
<p>The opcode number is a simple unsigned integer that only has meaning to a
|
|
specific backend. All of the instructions for a target should be defined in
|
|
the <tt>*InstrInfo.td</tt> file for the target. The opcode enum values are
|
|
auto-generated from this description. The <tt>MachineInstr</tt> class does
|
|
not have any information about how to interpret the instruction (i.e., what
|
|
the semantics of the instruction are); for that you must refer to the
|
|
<tt><a href="#targetinstrinfo">TargetInstrInfo</a></tt> class.</p>
|
|
|
|
<p>The operands of a machine instruction can be of several different types: a
|
|
register reference, a constant integer, a basic block reference, etc. In
|
|
addition, a machine operand should be marked as a def or a use of the value
|
|
(though only registers are allowed to be defs).</p>
|
|
|
|
<p>By convention, the LLVM code generator orders instruction operands so that
|
|
all register definitions come before the register uses, even on architectures
|
|
that are normally printed in other orders. For example, the SPARC add
|
|
instruction: "<tt>add %i1, %i2, %i3</tt>" adds the "%i1", and "%i2" registers
|
|
and stores the result into the "%i3" register. In the LLVM code generator,
|
|
the operands should be stored as "<tt>%i3, %i1, %i2</tt>": with the
|
|
destination first.</p>
|
|
|
|
<p>Keeping destination (definition) operands at the beginning of the operand
|
|
list has several advantages. In particular, the debugging printer will print
|
|
the instruction like this:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
%r3 = add %i1, %i2
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Also if the first operand is a def, it is easier to <a href="#buildmi">create
|
|
instructions</a> whose only def is the first operand.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="buildmi">Using the <tt>MachineInstrBuilder.h</tt> functions</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>Machine instructions are created by using the <tt>BuildMI</tt> functions,
|
|
located in the <tt>include/llvm/CodeGen/MachineInstrBuilder.h</tt> file. The
|
|
<tt>BuildMI</tt> functions make it easy to build arbitrary machine
|
|
instructions. Usage of the <tt>BuildMI</tt> functions look like this:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
// Create a 'DestReg = mov 42' (rendered in X86 assembly as 'mov DestReg, 42')
|
|
// instruction. The '1' specifies how many operands will be added.
|
|
MachineInstr *MI = BuildMI(X86::MOV32ri, 1, DestReg).addImm(42);
|
|
|
|
// Create the same instr, but insert it at the end of a basic block.
|
|
MachineBasicBlock &MBB = ...
|
|
BuildMI(MBB, X86::MOV32ri, 1, DestReg).addImm(42);
|
|
|
|
// Create the same instr, but insert it before a specified iterator point.
|
|
MachineBasicBlock::iterator MBBI = ...
|
|
BuildMI(MBB, MBBI, X86::MOV32ri, 1, DestReg).addImm(42);
|
|
|
|
// Create a 'cmp Reg, 0' instruction, no destination reg.
|
|
MI = BuildMI(X86::CMP32ri, 2).addReg(Reg).addImm(0);
|
|
// Create an 'sahf' instruction which takes no operands and stores nothing.
|
|
MI = BuildMI(X86::SAHF, 0);
|
|
|
|
// Create a self looping branch instruction.
|
|
BuildMI(MBB, X86::JNE, 1).addMBB(&MBB);
|
|
</pre>
|
|
</div>
|
|
|
|
<p>The key thing to remember with the <tt>BuildMI</tt> functions is that you
|
|
have to specify the number of operands that the machine instruction will
|
|
take. This allows for efficient memory allocation. You also need to specify
|
|
if operands default to be uses of values, not definitions. If you need to
|
|
add a definition operand (other than the optional destination register), you
|
|
must explicitly mark it as such:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
MI.addReg(Reg, RegState::Define);
|
|
</pre>
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="fixedregs">Fixed (preassigned) registers</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>One important issue that the code generator needs to be aware of is the
|
|
presence of fixed registers. In particular, there are often places in the
|
|
instruction stream where the register allocator <em>must</em> arrange for a
|
|
particular value to be in a particular register. This can occur due to
|
|
limitations of the instruction set (e.g., the X86 can only do a 32-bit divide
|
|
with the <tt>EAX</tt>/<tt>EDX</tt> registers), or external factors like
|
|
calling conventions. In any case, the instruction selector should emit code
|
|
that copies a virtual register into or out of a physical register when
|
|
needed.</p>
|
|
|
|
<p>For example, consider this simple LLVM example:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
define i32 @test(i32 %X, i32 %Y) {
|
|
%Z = udiv i32 %X, %Y
|
|
ret i32 %Z
|
|
}
|
|
</pre>
|
|
</div>
|
|
|
|
<p>The X86 instruction selector produces this machine code for the <tt>div</tt>
|
|
and <tt>ret</tt> (use "<tt>llc X.bc -march=x86 -print-machineinstrs</tt>" to
|
|
get this):</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
;; Start of div
|
|
%EAX = mov %reg1024 ;; Copy X (in reg1024) into EAX
|
|
%reg1027 = sar %reg1024, 31
|
|
%EDX = mov %reg1027 ;; Sign extend X into EDX
|
|
idiv %reg1025 ;; Divide by Y (in reg1025)
|
|
%reg1026 = mov %EAX ;; Read the result (Z) out of EAX
|
|
|
|
;; Start of ret
|
|
%EAX = mov %reg1026 ;; 32-bit return value goes in EAX
|
|
ret
|
|
</pre>
|
|
</div>
|
|
|
|
<p>By the end of code generation, the register allocator has coalesced the
|
|
registers and deleted the resultant identity moves producing the following
|
|
code:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
;; X is in EAX, Y is in ECX
|
|
mov %EAX, %EDX
|
|
sar %EDX, 31
|
|
idiv %ECX
|
|
ret
|
|
</pre>
|
|
</div>
|
|
|
|
<p>This approach is extremely general (if it can handle the X86 architecture, it
|
|
can handle anything!) and allows all of the target specific knowledge about
|
|
the instruction stream to be isolated in the instruction selector. Note that
|
|
physical registers should have a short lifetime for good code generation, and
|
|
all physical registers are assumed dead on entry to and exit from basic
|
|
blocks (before register allocation). Thus, if you need a value to be live
|
|
across basic block boundaries, it <em>must</em> live in a virtual
|
|
register.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="ssa">Machine code in SSA form</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p><tt>MachineInstr</tt>'s are initially selected in SSA-form, and are
|
|
maintained in SSA-form until register allocation happens. For the most part,
|
|
this is trivially simple since LLVM is already in SSA form; LLVM PHI nodes
|
|
become machine code PHI nodes, and virtual registers are only allowed to have
|
|
a single definition.</p>
|
|
|
|
<p>After register allocation, machine code is no longer in SSA-form because
|
|
there are no virtual registers left in the code.</p>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="machinebasicblock">The <tt>MachineBasicBlock</tt> class</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The <tt>MachineBasicBlock</tt> class contains a list of machine instructions
|
|
(<tt><a href="#machineinstr">MachineInstr</a></tt> instances). It roughly
|
|
corresponds to the LLVM code input to the instruction selector, but there can
|
|
be a one-to-many mapping (i.e. one LLVM basic block can map to multiple
|
|
machine basic blocks). The <tt>MachineBasicBlock</tt> class has a
|
|
"<tt>getBasicBlock</tt>" method, which returns the LLVM basic block that it
|
|
comes from.</p>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="machinefunction">The <tt>MachineFunction</tt> class</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The <tt>MachineFunction</tt> class contains a list of machine basic blocks
|
|
(<tt><a href="#machinebasicblock">MachineBasicBlock</a></tt> instances). It
|
|
corresponds one-to-one with the LLVM function input to the instruction
|
|
selector. In addition to a list of basic blocks,
|
|
the <tt>MachineFunction</tt> contains a a <tt>MachineConstantPool</tt>,
|
|
a <tt>MachineFrameInfo</tt>, a <tt>MachineFunctionInfo</tt>, and a
|
|
<tt>MachineRegisterInfo</tt>. See
|
|
<tt>include/llvm/CodeGen/MachineFunction.h</tt> for more information.</p>
|
|
|
|
</div>
|
|
|
|
<!-- *********************************************************************** -->
|
|
<div class="doc_section">
|
|
<a name="codegenalgs">Target-independent code generation algorithms</a>
|
|
</div>
|
|
<!-- *********************************************************************** -->
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>This section documents the phases described in the
|
|
<a href="#high-level-design">high-level design of the code generator</a>.
|
|
It explains how they work and some of the rationale behind their design.</p>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="instselect">Instruction Selection</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>Instruction Selection is the process of translating LLVM code presented to
|
|
the code generator into target-specific machine instructions. There are
|
|
several well-known ways to do this in the literature. LLVM uses a
|
|
SelectionDAG based instruction selector.</p>
|
|
|
|
<p>Portions of the DAG instruction selector are generated from the target
|
|
description (<tt>*.td</tt>) files. Our goal is for the entire instruction
|
|
selector to be generated from these <tt>.td</tt> files, though currently
|
|
there are still things that require custom C++ code.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="selectiondag_intro">Introduction to SelectionDAGs</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The SelectionDAG provides an abstraction for code representation in a way
|
|
that is amenable to instruction selection using automatic techniques
|
|
(e.g. dynamic-programming based optimal pattern matching selectors). It is
|
|
also well-suited to other phases of code generation; in particular,
|
|
instruction scheduling (SelectionDAG's are very close to scheduling DAGs
|
|
post-selection). Additionally, the SelectionDAG provides a host
|
|
representation where a large variety of very-low-level (but
|
|
target-independent) <a href="#selectiondag_optimize">optimizations</a> may be
|
|
performed; ones which require extensive information about the instructions
|
|
efficiently supported by the target.</p>
|
|
|
|
<p>The SelectionDAG is a Directed-Acyclic-Graph whose nodes are instances of the
|
|
<tt>SDNode</tt> class. The primary payload of the <tt>SDNode</tt> is its
|
|
operation code (Opcode) that indicates what operation the node performs and
|
|
the operands to the operation. The various operation node types are
|
|
described at the top of the <tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt>
|
|
file.</p>
|
|
|
|
<p>Although most operations define a single value, each node in the graph may
|
|
define multiple values. For example, a combined div/rem operation will
|
|
define both the dividend and the remainder. Many other situations require
|
|
multiple values as well. Each node also has some number of operands, which
|
|
are edges to the node defining the used value. Because nodes may define
|
|
multiple values, edges are represented by instances of the <tt>SDValue</tt>
|
|
class, which is a <tt><SDNode, unsigned></tt> pair, indicating the node
|
|
and result value being used, respectively. Each value produced by
|
|
an <tt>SDNode</tt> has an associated <tt>MVT</tt> (Machine Value Type)
|
|
indicating what the type of the value is.</p>
|
|
|
|
<p>SelectionDAGs contain two different kinds of values: those that represent
|
|
data flow and those that represent control flow dependencies. Data values
|
|
are simple edges with an integer or floating point value type. Control edges
|
|
are represented as "chain" edges which are of type <tt>MVT::Other</tt>.
|
|
These edges provide an ordering between nodes that have side effects (such as
|
|
loads, stores, calls, returns, etc). All nodes that have side effects should
|
|
take a token chain as input and produce a new one as output. By convention,
|
|
token chain inputs are always operand #0, and chain results are always the
|
|
last value produced by an operation.</p>
|
|
|
|
<p>A SelectionDAG has designated "Entry" and "Root" nodes. The Entry node is
|
|
always a marker node with an Opcode of <tt>ISD::EntryToken</tt>. The Root
|
|
node is the final side-effecting node in the token chain. For example, in a
|
|
single basic block function it would be the return node.</p>
|
|
|
|
<p>One important concept for SelectionDAGs is the notion of a "legal" vs.
|
|
"illegal" DAG. A legal DAG for a target is one that only uses supported
|
|
operations and supported types. On a 32-bit PowerPC, for example, a DAG with
|
|
a value of type i1, i8, i16, or i64 would be illegal, as would a DAG that
|
|
uses a SREM or UREM operation. The
|
|
<a href="#selectinodag_legalize_types">legalize types</a> and
|
|
<a href="#selectiondag_legalize">legalize operations</a> phases are
|
|
responsible for turning an illegal DAG into a legal DAG.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="selectiondag_process">SelectionDAG Instruction Selection Process</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>SelectionDAG-based instruction selection consists of the following steps:</p>
|
|
|
|
<ol>
|
|
<li><a href="#selectiondag_build">Build initial DAG</a> — This stage
|
|
performs a simple translation from the input LLVM code to an illegal
|
|
SelectionDAG.</li>
|
|
|
|
<li><a href="#selectiondag_optimize">Optimize SelectionDAG</a> — This
|
|
stage performs simple optimizations on the SelectionDAG to simplify it,
|
|
and recognize meta instructions (like rotates
|
|
and <tt>div</tt>/<tt>rem</tt> pairs) for targets that support these meta
|
|
operations. This makes the resultant code more efficient and
|
|
the <a href="#selectiondag_select">select instructions from DAG</a> phase
|
|
(below) simpler.</li>
|
|
|
|
<li><a href="#selectiondag_legalize_types">Legalize SelectionDAG Types</a>
|
|
— This stage transforms SelectionDAG nodes to eliminate any types
|
|
that are unsupported on the target.</li>
|
|
|
|
<li><a href="#selectiondag_optimize">Optimize SelectionDAG</a> — The
|
|
SelectionDAG optimizer is run to clean up redundancies exposed by type
|
|
legalization.</li>
|
|
|
|
<li><a href="#selectiondag_legalize">Legalize SelectionDAG Types</a> —
|
|
This stage transforms SelectionDAG nodes to eliminate any types that are
|
|
unsupported on the target.</li>
|
|
|
|
<li><a href="#selectiondag_optimize">Optimize SelectionDAG</a> — The
|
|
SelectionDAG optimizer is run to eliminate inefficiencies introduced by
|
|
operation legalization.</li>
|
|
|
|
<li><a href="#selectiondag_select">Select instructions from DAG</a> —
|
|
Finally, the target instruction selector matches the DAG operations to
|
|
target instructions. This process translates the target-independent input
|
|
DAG into another DAG of target instructions.</li>
|
|
|
|
<li><a href="#selectiondag_sched">SelectionDAG Scheduling and Formation</a>
|
|
— The last phase assigns a linear order to the instructions in the
|
|
target-instruction DAG and emits them into the MachineFunction being
|
|
compiled. This step uses traditional prepass scheduling techniques.</li>
|
|
</ol>
|
|
|
|
<p>After all of these steps are complete, the SelectionDAG is destroyed and the
|
|
rest of the code generation passes are run.</p>
|
|
|
|
<p>One great way to visualize what is going on here is to take advantage of a
|
|
few LLC command line options. The following options pop up a window
|
|
displaying the SelectionDAG at specific times (if you only get errors printed
|
|
to the console while using this, you probably
|
|
<a href="ProgrammersManual.html#ViewGraph">need to configure your system</a>
|
|
to add support for it).</p>
|
|
|
|
<ul>
|
|
<li><tt>-view-dag-combine1-dags</tt> displays the DAG after being built,
|
|
before the first optimization pass.</li>
|
|
|
|
<li><tt>-view-legalize-dags</tt> displays the DAG before Legalization.</li>
|
|
|
|
<li><tt>-view-dag-combine2-dags</tt> displays the DAG before the second
|
|
optimization pass.</li>
|
|
|
|
<li><tt>-view-isel-dags</tt> displays the DAG before the Select phase.</li>
|
|
|
|
<li><tt>-view-sched-dags</tt> displays the DAG before Scheduling.</li>
|
|
</ul>
|
|
|
|
<p>The <tt>-view-sunit-dags</tt> displays the Scheduler's dependency graph.
|
|
This graph is based on the final SelectionDAG, with nodes that must be
|
|
scheduled together bundled into a single scheduling-unit node, and with
|
|
immediate operands and other nodes that aren't relevant for scheduling
|
|
omitted.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="selectiondag_build">Initial SelectionDAG Construction</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The initial SelectionDAG is naïvely peephole expanded from the LLVM
|
|
input by the <tt>SelectionDAGLowering</tt> class in the
|
|
<tt>lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp</tt> file. The intent of
|
|
this pass is to expose as much low-level, target-specific details to the
|
|
SelectionDAG as possible. This pass is mostly hard-coded (e.g. an
|
|
LLVM <tt>add</tt> turns into an <tt>SDNode add</tt> while a
|
|
<tt>getelementptr</tt> is expanded into the obvious arithmetic). This pass
|
|
requires target-specific hooks to lower calls, returns, varargs, etc. For
|
|
these features, the <tt><a href="#targetlowering">TargetLowering</a></tt>
|
|
interface is used.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="selectiondag_legalize_types">SelectionDAG LegalizeTypes Phase</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The Legalize phase is in charge of converting a DAG to only use the types
|
|
that are natively supported by the target.</p>
|
|
|
|
<p>There are two main ways of converting values of unsupported scalar types to
|
|
values of supported types: converting small types to larger types
|
|
("promoting"), and breaking up large integer types into smaller ones
|
|
("expanding"). For example, a target might require that all f32 values are
|
|
promoted to f64 and that all i1/i8/i16 values are promoted to i32. The same
|
|
target might require that all i64 values be expanded into pairs of i32
|
|
values. These changes can insert sign and zero extensions as needed to make
|
|
sure that the final code has the same behavior as the input.</p>
|
|
|
|
<p>There are two main ways of converting values of unsupported vector types to
|
|
value of supported types: splitting vector types, multiple times if
|
|
necessary, until a legal type is found, and extending vector types by adding
|
|
elements to the end to round them out to legal types ("widening"). If a
|
|
vector gets split all the way down to single-element parts with no supported
|
|
vector type being found, the elements are converted to scalars
|
|
("scalarizing").</p>
|
|
|
|
<p>A target implementation tells the legalizer which types are supported (and
|
|
which register class to use for them) by calling the
|
|
<tt>addRegisterClass</tt> method in its TargetLowering constructor.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="selectiondag_legalize">SelectionDAG Legalize Phase</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The Legalize phase is in charge of converting a DAG to only use the
|
|
operations that are natively supported by the target.</p>
|
|
|
|
<p>Targets often have weird constraints, such as not supporting every operation
|
|
on every supported datatype (e.g. X86 does not support byte conditional moves
|
|
and PowerPC does not support sign-extending loads from a 16-bit memory
|
|
location). Legalize takes care of this by open-coding another sequence of
|
|
operations to emulate the operation ("expansion"), by promoting one type to a
|
|
larger type that supports the operation ("promotion"), or by using a
|
|
target-specific hook to implement the legalization ("custom").</p>
|
|
|
|
<p>A target implementation tells the legalizer which operations are not
|
|
supported (and which of the above three actions to take) by calling the
|
|
<tt>setOperationAction</tt> method in its <tt>TargetLowering</tt>
|
|
constructor.</p>
|
|
|
|
<p>Prior to the existence of the Legalize passes, we required that every target
|
|
<a href="#selectiondag_optimize">selector</a> supported and handled every
|
|
operator and type even if they are not natively supported. The introduction
|
|
of the Legalize phases allows all of the canonicalization patterns to be
|
|
shared across targets, and makes it very easy to optimize the canonicalized
|
|
code because it is still in the form of a DAG.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="selectiondag_optimize">SelectionDAG Optimization Phase: the DAG
|
|
Combiner</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The SelectionDAG optimization phase is run multiple times for code
|
|
generation, immediately after the DAG is built and once after each
|
|
legalization. The first run of the pass allows the initial code to be
|
|
cleaned up (e.g. performing optimizations that depend on knowing that the
|
|
operators have restricted type inputs). Subsequent runs of the pass clean up
|
|
the messy code generated by the Legalize passes, which allows Legalize to be
|
|
very simple (it can focus on making code legal instead of focusing on
|
|
generating <em>good</em> and legal code).</p>
|
|
|
|
<p>One important class of optimizations performed is optimizing inserted sign
|
|
and zero extension instructions. We currently use ad-hoc techniques, but
|
|
could move to more rigorous techniques in the future. Here are some good
|
|
papers on the subject:</p>
|
|
|
|
<p>"<a href="http://www.eecs.harvard.edu/~nr/pubs/widen-abstract.html">Widening
|
|
integer arithmetic</a>"<br>
|
|
Kevin Redwine and Norman Ramsey<br>
|
|
International Conference on Compiler Construction (CC) 2004</p>
|
|
|
|
<p>"<a href="http://portal.acm.org/citation.cfm?doid=512529.512552">Effective
|
|
sign extension elimination</a>"<br>
|
|
Motohiro Kawahito, Hideaki Komatsu, and Toshio Nakatani<br>
|
|
Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language Design
|
|
and Implementation.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="selectiondag_select">SelectionDAG Select Phase</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The Select phase is the bulk of the target-specific code for instruction
|
|
selection. This phase takes a legal SelectionDAG as input, pattern matches
|
|
the instructions supported by the target to this DAG, and produces a new DAG
|
|
of target code. For example, consider the following LLVM fragment:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
%t1 = add float %W, %X
|
|
%t2 = mul float %t1, %Y
|
|
%t3 = add float %t2, %Z
|
|
</pre>
|
|
</div>
|
|
|
|
<p>This LLVM code corresponds to a SelectionDAG that looks basically like
|
|
this:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
(fadd:f32 (fmul:f32 (fadd:f32 W, X), Y), Z)
|
|
</pre>
|
|
</div>
|
|
|
|
<p>If a target supports floating point multiply-and-add (FMA) operations, one of
|
|
the adds can be merged with the multiply. On the PowerPC, for example, the
|
|
output of the instruction selector might look like this DAG:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
(FMADDS (FADDS W, X), Y, Z)
|
|
</pre>
|
|
</div>
|
|
|
|
<p>The <tt>FMADDS</tt> instruction is a ternary instruction that multiplies its
|
|
first two operands and adds the third (as single-precision floating-point
|
|
numbers). The <tt>FADDS</tt> instruction is a simple binary single-precision
|
|
add instruction. To perform this pattern match, the PowerPC backend includes
|
|
the following instruction definitions:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
def FMADDS : AForm_1<59, 29,
|
|
(ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRC, F4RC:$FRB),
|
|
"fmadds $FRT, $FRA, $FRC, $FRB",
|
|
[<b>(set F4RC:$FRT, (fadd (fmul F4RC:$FRA, F4RC:$FRC),
|
|
F4RC:$FRB))</b>]>;
|
|
def FADDS : AForm_2<59, 21,
|
|
(ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRB),
|
|
"fadds $FRT, $FRA, $FRB",
|
|
[<b>(set F4RC:$FRT, (fadd F4RC:$FRA, F4RC:$FRB))</b>]>;
|
|
</pre>
|
|
</div>
|
|
|
|
<p>The portion of the instruction definition in bold indicates the pattern used
|
|
to match the instruction. The DAG operators
|
|
(like <tt>fmul</tt>/<tt>fadd</tt>) are defined in
|
|
the <tt>lib/Target/TargetSelectionDAG.td</tt> file. "<tt>F4RC</tt>" is the
|
|
register class of the input and result values.</p>
|
|
|
|
<p>The TableGen DAG instruction selector generator reads the instruction
|
|
patterns in the <tt>.td</tt> file and automatically builds parts of the
|
|
pattern matching code for your target. It has the following strengths:</p>
|
|
|
|
<ul>
|
|
<li>At compiler-compiler time, it analyzes your instruction patterns and tells
|
|
you if your patterns make sense or not.</li>
|
|
|
|
<li>It can handle arbitrary constraints on operands for the pattern match. In
|
|
particular, it is straight-forward to say things like "match any immediate
|
|
that is a 13-bit sign-extended value". For examples, see the
|
|
<tt>immSExt16</tt> and related <tt>tblgen</tt> classes in the PowerPC
|
|
backend.</li>
|
|
|
|
<li>It knows several important identities for the patterns defined. For
|
|
example, it knows that addition is commutative, so it allows the
|
|
<tt>FMADDS</tt> pattern above to match "<tt>(fadd X, (fmul Y, Z))</tt>" as
|
|
well as "<tt>(fadd (fmul X, Y), Z)</tt>", without the target author having
|
|
to specially handle this case.</li>
|
|
|
|
<li>It has a full-featured type-inferencing system. In particular, you should
|
|
rarely have to explicitly tell the system what type parts of your patterns
|
|
are. In the <tt>FMADDS</tt> case above, we didn't have to tell
|
|
<tt>tblgen</tt> that all of the nodes in the pattern are of type 'f32'.
|
|
It was able to infer and propagate this knowledge from the fact that
|
|
<tt>F4RC</tt> has type 'f32'.</li>
|
|
|
|
<li>Targets can define their own (and rely on built-in) "pattern fragments".
|
|
Pattern fragments are chunks of reusable patterns that get inlined into
|
|
your patterns during compiler-compiler time. For example, the integer
|
|
"<tt>(not x)</tt>" operation is actually defined as a pattern fragment
|
|
that expands as "<tt>(xor x, -1)</tt>", since the SelectionDAG does not
|
|
have a native '<tt>not</tt>' operation. Targets can define their own
|
|
short-hand fragments as they see fit. See the definition of
|
|
'<tt>not</tt>' and '<tt>ineg</tt>' for examples.</li>
|
|
|
|
<li>In addition to instructions, targets can specify arbitrary patterns that
|
|
map to one or more instructions using the 'Pat' class. For example, the
|
|
PowerPC has no way to load an arbitrary integer immediate into a register
|
|
in one instruction. To tell tblgen how to do this, it defines:
|
|
<br>
|
|
<br>
|
|
<div class="doc_code">
|
|
<pre>
|
|
// Arbitrary immediate support. Implement in terms of LIS/ORI.
|
|
def : Pat<(i32 imm:$imm),
|
|
(ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm))>;
|
|
</pre>
|
|
</div>
|
|
<br>
|
|
If none of the single-instruction patterns for loading an immediate into a
|
|
register match, this will be used. This rule says "match an arbitrary i32
|
|
immediate, turning it into an <tt>ORI</tt> ('or a 16-bit immediate') and
|
|
an <tt>LIS</tt> ('load 16-bit immediate, where the immediate is shifted to
|
|
the left 16 bits') instruction". To make this work, the
|
|
<tt>LO16</tt>/<tt>HI16</tt> node transformations are used to manipulate
|
|
the input immediate (in this case, take the high or low 16-bits of the
|
|
immediate).</li>
|
|
|
|
<li>While the system does automate a lot, it still allows you to write custom
|
|
C++ code to match special cases if there is something that is hard to
|
|
express.</li>
|
|
</ul>
|
|
|
|
<p>While it has many strengths, the system currently has some limitations,
|
|
primarily because it is a work in progress and is not yet finished:</p>
|
|
|
|
<ul>
|
|
<li>Overall, there is no way to define or match SelectionDAG nodes that define
|
|
multiple values (e.g. <tt>SMUL_LOHI</tt>, <tt>LOAD</tt>, <tt>CALL</tt>,
|
|
etc). This is the biggest reason that you currently still <em>have
|
|
to</em> write custom C++ code for your instruction selector.</li>
|
|
|
|
<li>There is no great way to support matching complex addressing modes yet.
|
|
In the future, we will extend pattern fragments to allow them to define
|
|
multiple values (e.g. the four operands of the <a href="#x86_memory">X86
|
|
addressing mode</a>, which are currently matched with custom C++ code).
|
|
In addition, we'll extend fragments so that a fragment can match multiple
|
|
different patterns.</li>
|
|
|
|
<li>We don't automatically infer flags like isStore/isLoad yet.</li>
|
|
|
|
<li>We don't automatically generate the set of supported registers and
|
|
operations for the <a href="#selectiondag_legalize">Legalizer</a>
|
|
yet.</li>
|
|
|
|
<li>We don't have a way of tying in custom legalized nodes yet.</li>
|
|
</ul>
|
|
|
|
<p>Despite these limitations, the instruction selector generator is still quite
|
|
useful for most of the binary and logical operations in typical instruction
|
|
sets. If you run into any problems or can't figure out how to do something,
|
|
please let Chris know!</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="selectiondag_sched">SelectionDAG Scheduling and Formation Phase</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The scheduling phase takes the DAG of target instructions from the selection
|
|
phase and assigns an order. The scheduler can pick an order depending on
|
|
various constraints of the machines (i.e. order for minimal register pressure
|
|
or try to cover instruction latencies). Once an order is established, the
|
|
DAG is converted to a list
|
|
of <tt><a href="#machineinstr">MachineInstr</a></tt>s and the SelectionDAG is
|
|
destroyed.</p>
|
|
|
|
<p>Note that this phase is logically separate from the instruction selection
|
|
phase, but is tied to it closely in the code because it operates on
|
|
SelectionDAGs.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="selectiondag_future">Future directions for the SelectionDAG</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<ol>
|
|
<li>Optional function-at-a-time selection.</li>
|
|
|
|
<li>Auto-generate entire selector from <tt>.td</tt> file.</li>
|
|
</ol>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="ssamco">SSA-based Machine Code Optimizations</a>
|
|
</div>
|
|
<div class="doc_text"><p>To Be Written</p></div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="liveintervals">Live Intervals</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>Live Intervals are the ranges (intervals) where a variable is <i>live</i>.
|
|
They are used by some <a href="#regalloc">register allocator</a> passes to
|
|
determine if two or more virtual registers which require the same physical
|
|
register are live at the same point in the program (i.e., they conflict).
|
|
When this situation occurs, one virtual register must be <i>spilled</i>.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="livevariable_analysis">Live Variable Analysis</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The first step in determining the live intervals of variables is to calculate
|
|
the set of registers that are immediately dead after the instruction (i.e.,
|
|
the instruction calculates the value, but it is never used) and the set of
|
|
registers that are used by the instruction, but are never used after the
|
|
instruction (i.e., they are killed). Live variable information is computed
|
|
for each <i>virtual</i> register and <i>register allocatable</i> physical
|
|
register in the function. This is done in a very efficient manner because it
|
|
uses SSA to sparsely compute lifetime information for virtual registers
|
|
(which are in SSA form) and only has to track physical registers within a
|
|
block. Before register allocation, LLVM can assume that physical registers
|
|
are only live within a single basic block. This allows it to do a single,
|
|
local analysis to resolve physical register lifetimes within each basic
|
|
block. If a physical register is not register allocatable (e.g., a stack
|
|
pointer or condition codes), it is not tracked.</p>
|
|
|
|
<p>Physical registers may be live in to or out of a function. Live in values are
|
|
typically arguments in registers. Live out values are typically return values
|
|
in registers. Live in values are marked as such, and are given a dummy
|
|
"defining" instruction during live intervals analysis. If the last basic
|
|
block of a function is a <tt>return</tt>, then it's marked as using all live
|
|
out values in the function.</p>
|
|
|
|
<p><tt>PHI</tt> nodes need to be handled specially, because the calculation of
|
|
the live variable information from a depth first traversal of the CFG of the
|
|
function won't guarantee that a virtual register used by the <tt>PHI</tt>
|
|
node is defined before it's used. When a <tt>PHI</tt> node is encountered,
|
|
only the definition is handled, because the uses will be handled in other
|
|
basic blocks.</p>
|
|
|
|
<p>For each <tt>PHI</tt> node of the current basic block, we simulate an
|
|
assignment at the end of the current basic block and traverse the successor
|
|
basic blocks. If a successor basic block has a <tt>PHI</tt> node and one of
|
|
the <tt>PHI</tt> node's operands is coming from the current basic block, then
|
|
the variable is marked as <i>alive</i> within the current basic block and all
|
|
of its predecessor basic blocks, until the basic block with the defining
|
|
instruction is encountered.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="liveintervals_analysis">Live Intervals Analysis</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>We now have the information available to perform the live intervals analysis
|
|
and build the live intervals themselves. We start off by numbering the basic
|
|
blocks and machine instructions. We then handle the "live-in" values. These
|
|
are in physical registers, so the physical register is assumed to be killed
|
|
by the end of the basic block. Live intervals for virtual registers are
|
|
computed for some ordering of the machine instructions <tt>[1, N]</tt>. A
|
|
live interval is an interval <tt>[i, j)</tt>, where <tt>1 <= i <= j
|
|
< N</tt>, for which a variable is live.</p>
|
|
|
|
<p><i><b>More to come...</b></i></p>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="regalloc">Register Allocation</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The <i>Register Allocation problem</i> consists in mapping a program
|
|
<i>P<sub>v</sub></i>, that can use an unbounded number of virtual registers,
|
|
to a program <i>P<sub>p</sub></i> that contains a finite (possibly small)
|
|
number of physical registers. Each target architecture has a different number
|
|
of physical registers. If the number of physical registers is not enough to
|
|
accommodate all the virtual registers, some of them will have to be mapped
|
|
into memory. These virtuals are called <i>spilled virtuals</i>.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
|
|
<div class="doc_subsubsection">
|
|
<a name="regAlloc_represent">How registers are represented in LLVM</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>In LLVM, physical registers are denoted by integer numbers that normally
|
|
range from 1 to 1023. To see how this numbering is defined for a particular
|
|
architecture, you can read the <tt>GenRegisterNames.inc</tt> file for that
|
|
architecture. For instance, by
|
|
inspecting <tt>lib/Target/X86/X86GenRegisterNames.inc</tt> we see that the
|
|
32-bit register <tt>EAX</tt> is denoted by 15, and the MMX register
|
|
<tt>MM0</tt> is mapped to 48.</p>
|
|
|
|
<p>Some architectures contain registers that share the same physical location. A
|
|
notable example is the X86 platform. For instance, in the X86 architecture,
|
|
the registers <tt>EAX</tt>, <tt>AX</tt> and <tt>AL</tt> share the first eight
|
|
bits. These physical registers are marked as <i>aliased</i> in LLVM. Given a
|
|
particular architecture, you can check which registers are aliased by
|
|
inspecting its <tt>RegisterInfo.td</tt> file. Moreover, the method
|
|
<tt>TargetRegisterInfo::getAliasSet(p_reg)</tt> returns an array containing
|
|
all the physical registers aliased to the register <tt>p_reg</tt>.</p>
|
|
|
|
<p>Physical registers, in LLVM, are grouped in <i>Register Classes</i>.
|
|
Elements in the same register class are functionally equivalent, and can be
|
|
interchangeably used. Each virtual register can only be mapped to physical
|
|
registers of a particular class. For instance, in the X86 architecture, some
|
|
virtuals can only be allocated to 8 bit registers. A register class is
|
|
described by <tt>TargetRegisterClass</tt> objects. To discover if a virtual
|
|
register is compatible with a given physical, this code can be used:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
bool RegMapping_Fer::compatible_class(MachineFunction &mf,
|
|
unsigned v_reg,
|
|
unsigned p_reg) {
|
|
assert(TargetRegisterInfo::isPhysicalRegister(p_reg) &&
|
|
"Target register must be physical");
|
|
const TargetRegisterClass *trc = mf.getRegInfo().getRegClass(v_reg);
|
|
return trc->contains(p_reg);
|
|
}
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Sometimes, mostly for debugging purposes, it is useful to change the number
|
|
of physical registers available in the target architecture. This must be done
|
|
statically, inside the <tt>TargetRegsterInfo.td</tt> file. Just <tt>grep</tt>
|
|
for <tt>RegisterClass</tt>, the last parameter of which is a list of
|
|
registers. Just commenting some out is one simple way to avoid them being
|
|
used. A more polite way is to explicitly exclude some registers from
|
|
the <i>allocation order</i>. See the definition of the <tt>GR8</tt> register
|
|
class in <tt>lib/Target/X86/X86RegisterInfo.td</tt> for an example of this.
|
|
</p>
|
|
|
|
<p>Virtual registers are also denoted by integer numbers. Contrary to physical
|
|
registers, different virtual registers never share the same number. The
|
|
smallest virtual register is normally assigned the number 1024. This may
|
|
change, so, in order to know which is the first virtual register, you should
|
|
access <tt>TargetRegisterInfo::FirstVirtualRegister</tt>. Any register whose
|
|
number is greater than or equal
|
|
to <tt>TargetRegisterInfo::FirstVirtualRegister</tt> is considered a virtual
|
|
register. Whereas physical registers are statically defined in
|
|
a <tt>TargetRegisterInfo.td</tt> file and cannot be created by the
|
|
application developer, that is not the case with virtual registers. In order
|
|
to create new virtual registers, use the
|
|
method <tt>MachineRegisterInfo::createVirtualRegister()</tt>. This method
|
|
will return a virtual register with the highest code.</p>
|
|
|
|
<p>Before register allocation, the operands of an instruction are mostly virtual
|
|
registers, although physical registers may also be used. In order to check if
|
|
a given machine operand is a register, use the boolean
|
|
function <tt>MachineOperand::isRegister()</tt>. To obtain the integer code of
|
|
a register, use <tt>MachineOperand::getReg()</tt>. An instruction may define
|
|
or use a register. For instance, <tt>ADD reg:1026 := reg:1025 reg:1024</tt>
|
|
defines the registers 1024, and uses registers 1025 and 1026. Given a
|
|
register operand, the method <tt>MachineOperand::isUse()</tt> informs if that
|
|
register is being used by the instruction. The
|
|
method <tt>MachineOperand::isDef()</tt> informs if that registers is being
|
|
defined.</p>
|
|
|
|
<p>We will call physical registers present in the LLVM bitcode before register
|
|
allocation <i>pre-colored registers</i>. Pre-colored registers are used in
|
|
many different situations, for instance, to pass parameters of functions
|
|
calls, and to store results of particular instructions. There are two types
|
|
of pre-colored registers: the ones <i>implicitly</i> defined, and
|
|
those <i>explicitly</i> defined. Explicitly defined registers are normal
|
|
operands, and can be accessed
|
|
with <tt>MachineInstr::getOperand(int)::getReg()</tt>. In order to check
|
|
which registers are implicitly defined by an instruction, use
|
|
the <tt>TargetInstrInfo::get(opcode)::ImplicitDefs</tt>,
|
|
where <tt>opcode</tt> is the opcode of the target instruction. One important
|
|
difference between explicit and implicit physical registers is that the
|
|
latter are defined statically for each instruction, whereas the former may
|
|
vary depending on the program being compiled. For example, an instruction
|
|
that represents a function call will always implicitly define or use the same
|
|
set of physical registers. To read the registers implicitly used by an
|
|
instruction,
|
|
use <tt>TargetInstrInfo::get(opcode)::ImplicitUses</tt>. Pre-colored
|
|
registers impose constraints on any register allocation algorithm. The
|
|
register allocator must make sure that none of them is been overwritten by
|
|
the values of virtual registers while still alive.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
|
|
<div class="doc_subsubsection">
|
|
<a name="regAlloc_howTo">Mapping virtual registers to physical registers</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>There are two ways to map virtual registers to physical registers (or to
|
|
memory slots). The first way, that we will call <i>direct mapping</i>, is
|
|
based on the use of methods of the classes <tt>TargetRegisterInfo</tt>,
|
|
and <tt>MachineOperand</tt>. The second way, that we will call <i>indirect
|
|
mapping</i>, relies on the <tt>VirtRegMap</tt> class in order to insert loads
|
|
and stores sending and getting values to and from memory.</p>
|
|
|
|
<p>The direct mapping provides more flexibility to the developer of the register
|
|
allocator; however, it is more error prone, and demands more implementation
|
|
work. Basically, the programmer will have to specify where load and store
|
|
instructions should be inserted in the target function being compiled in
|
|
order to get and store values in memory. To assign a physical register to a
|
|
virtual register present in a given operand,
|
|
use <tt>MachineOperand::setReg(p_reg)</tt>. To insert a store instruction,
|
|
use <tt>TargetRegisterInfo::storeRegToStackSlot(...)</tt>, and to insert a
|
|
load instruction, use <tt>TargetRegisterInfo::loadRegFromStackSlot</tt>.</p>
|
|
|
|
<p>The indirect mapping shields the application developer from the complexities
|
|
of inserting load and store instructions. In order to map a virtual register
|
|
to a physical one, use <tt>VirtRegMap::assignVirt2Phys(vreg, preg)</tt>. In
|
|
order to map a certain virtual register to memory,
|
|
use <tt>VirtRegMap::assignVirt2StackSlot(vreg)</tt>. This method will return
|
|
the stack slot where <tt>vreg</tt>'s value will be located. If it is
|
|
necessary to map another virtual register to the same stack slot,
|
|
use <tt>VirtRegMap::assignVirt2StackSlot(vreg, stack_location)</tt>. One
|
|
important point to consider when using the indirect mapping, is that even if
|
|
a virtual register is mapped to memory, it still needs to be mapped to a
|
|
physical register. This physical register is the location where the virtual
|
|
register is supposed to be found before being stored or after being
|
|
reloaded.</p>
|
|
|
|
<p>If the indirect strategy is used, after all the virtual registers have been
|
|
mapped to physical registers or stack slots, it is necessary to use a spiller
|
|
object to place load and store instructions in the code. Every virtual that
|
|
has been mapped to a stack slot will be stored to memory after been defined
|
|
and will be loaded before being used. The implementation of the spiller tries
|
|
to recycle load/store instructions, avoiding unnecessary instructions. For an
|
|
example of how to invoke the spiller,
|
|
see <tt>RegAllocLinearScan::runOnMachineFunction</tt>
|
|
in <tt>lib/CodeGen/RegAllocLinearScan.cpp</tt>.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="regAlloc_twoAddr">Handling two address instructions</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>With very rare exceptions (e.g., function calls), the LLVM machine code
|
|
instructions are three address instructions. That is, each instruction is
|
|
expected to define at most one register, and to use at most two registers.
|
|
However, some architectures use two address instructions. In this case, the
|
|
defined register is also one of the used register. For instance, an
|
|
instruction such as <tt>ADD %EAX, %EBX</tt>, in X86 is actually equivalent
|
|
to <tt>%EAX = %EAX + %EBX</tt>.</p>
|
|
|
|
<p>In order to produce correct code, LLVM must convert three address
|
|
instructions that represent two address instructions into true two address
|
|
instructions. LLVM provides the pass <tt>TwoAddressInstructionPass</tt> for
|
|
this specific purpose. It must be run before register allocation takes
|
|
place. After its execution, the resulting code may no longer be in SSA
|
|
form. This happens, for instance, in situations where an instruction such
|
|
as <tt>%a = ADD %b %c</tt> is converted to two instructions such as:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
%a = MOVE %b
|
|
%a = ADD %a %c
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Notice that, internally, the second instruction is represented as
|
|
<tt>ADD %a[def/use] %c</tt>. I.e., the register operand <tt>%a</tt> is both
|
|
used and defined by the instruction.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="regAlloc_ssaDecon">The SSA deconstruction phase</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>An important transformation that happens during register allocation is called
|
|
the <i>SSA Deconstruction Phase</i>. The SSA form simplifies many analyses
|
|
that are performed on the control flow graph of programs. However,
|
|
traditional instruction sets do not implement PHI instructions. Thus, in
|
|
order to generate executable code, compilers must replace PHI instructions
|
|
with other instructions that preserve their semantics.</p>
|
|
|
|
<p>There are many ways in which PHI instructions can safely be removed from the
|
|
target code. The most traditional PHI deconstruction algorithm replaces PHI
|
|
instructions with copy instructions. That is the strategy adopted by
|
|
LLVM. The SSA deconstruction algorithm is implemented
|
|
in <tt>lib/CodeGen/PHIElimination.cpp</tt>. In order to invoke this pass, the
|
|
identifier <tt>PHIEliminationID</tt> must be marked as required in the code
|
|
of the register allocator.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="regAlloc_fold">Instruction folding</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p><i>Instruction folding</i> is an optimization performed during register
|
|
allocation that removes unnecessary copy instructions. For instance, a
|
|
sequence of instructions such as:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
%EBX = LOAD %mem_address
|
|
%EAX = COPY %EBX
|
|
</pre>
|
|
</div>
|
|
|
|
<p>can be safely substituted by the single instruction:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
%EAX = LOAD %mem_address
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Instructions can be folded with
|
|
the <tt>TargetRegisterInfo::foldMemoryOperand(...)</tt> method. Care must be
|
|
taken when folding instructions; a folded instruction can be quite different
|
|
from the original
|
|
instruction. See <tt>LiveIntervals::addIntervalsForSpills</tt>
|
|
in <tt>lib/CodeGen/LiveIntervalAnalysis.cpp</tt> for an example of its
|
|
use.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
|
|
<div class="doc_subsubsection">
|
|
<a name="regAlloc_builtIn">Built in register allocators</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The LLVM infrastructure provides the application developer with three
|
|
different register allocators:</p>
|
|
|
|
<ul>
|
|
<li><i>Simple</i> — This is a very simple implementation that does not
|
|
keep values in registers across instructions. This register allocator
|
|
immediately spills every value right after it is computed, and reloads all
|
|
used operands from memory to temporary registers before each
|
|
instruction.</li>
|
|
|
|
<li><i>Local</i> — This register allocator is an improvement on the
|
|
<i>Simple</i> implementation. It allocates registers on a basic block
|
|
level, attempting to keep values in registers and reusing registers as
|
|
appropriate.</li>
|
|
|
|
<li><i>Linear Scan</i> — <i>The default allocator</i>. This is the
|
|
well-know linear scan register allocator. Whereas the
|
|
<i>Simple</i> and <i>Local</i> algorithms use a direct mapping
|
|
implementation technique, the <i>Linear Scan</i> implementation
|
|
uses a spiller in order to place load and stores.</li>
|
|
</ul>
|
|
|
|
<p>The type of register allocator used in <tt>llc</tt> can be chosen with the
|
|
command line option <tt>-regalloc=...</tt>:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
$ llc -regalloc=simple file.bc -o sp.s;
|
|
$ llc -regalloc=local file.bc -o lc.s;
|
|
$ llc -regalloc=linearscan file.bc -o ln.s;
|
|
</pre>
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="proepicode">Prolog/Epilog Code Insertion</a>
|
|
</div>
|
|
<div class="doc_text"><p>To Be Written</p></div>
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="latemco">Late Machine Code Optimizations</a>
|
|
</div>
|
|
<div class="doc_text"><p>To Be Written</p></div>
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="codeemit">Code Emission</a>
|
|
</div>
|
|
<div class="doc_text"><p>To Be Written</p></div>
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="codeemit_asm">Generating Assembly Code</a>
|
|
</div>
|
|
<div class="doc_text"><p>To Be Written</p></div>
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="codeemit_bin">Generating Binary Machine Code</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
<p>For the JIT or <tt>.o</tt> file writer</p>
|
|
</div>
|
|
|
|
|
|
<!-- *********************************************************************** -->
|
|
<div class="doc_section">
|
|
<a name="targetimpls">Target-specific Implementation Notes</a>
|
|
</div>
|
|
<!-- *********************************************************************** -->
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>This section of the document explains features or design decisions that are
|
|
specific to the code generator for a particular target.</p>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="tailcallopt">Tail call optimization</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>Tail call optimization, callee reusing the stack of the caller, is currently
|
|
supported on x86/x86-64 and PowerPC. It is performed if:</p>
|
|
|
|
<ul>
|
|
<li>Caller and callee have the calling convention <tt>fastcc</tt>.</li>
|
|
|
|
<li>The call is a tail call - in tail position (ret immediately follows call
|
|
and ret uses value of call or is void).</li>
|
|
|
|
<li>Option <tt>-tailcallopt</tt> is enabled.</li>
|
|
|
|
<li>Platform specific constraints are met.</li>
|
|
</ul>
|
|
|
|
<p>x86/x86-64 constraints:</p>
|
|
|
|
<ul>
|
|
<li>No variable argument lists are used.</li>
|
|
|
|
<li>On x86-64 when generating GOT/PIC code only module-local calls (visibility
|
|
= hidden or protected) are supported.</li>
|
|
</ul>
|
|
|
|
<p>PowerPC constraints:</p>
|
|
|
|
<ul>
|
|
<li>No variable argument lists are used.</li>
|
|
|
|
<li>No byval parameters are used.</li>
|
|
|
|
<li>On ppc32/64 GOT/PIC only module-local calls (visibility = hidden or protected) are supported.</li>
|
|
</ul>
|
|
|
|
<p>Example:</p>
|
|
|
|
<p>Call as <tt>llc -tailcallopt test.ll</tt>.</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
declare fastcc i32 @tailcallee(i32 inreg %a1, i32 inreg %a2, i32 %a3, i32 %a4)
|
|
|
|
define fastcc i32 @tailcaller(i32 %in1, i32 %in2) {
|
|
%l1 = add i32 %in1, %in2
|
|
%tmp = tail call fastcc i32 @tailcallee(i32 %in1 inreg, i32 %in2 inreg, i32 %in1, i32 %l1)
|
|
ret i32 %tmp
|
|
}
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Implications of <tt>-tailcallopt</tt>:</p>
|
|
|
|
<p>To support tail call optimization in situations where the callee has more
|
|
arguments than the caller a 'callee pops arguments' convention is used. This
|
|
currently causes each <tt>fastcc</tt> call that is not tail call optimized
|
|
(because one or more of above constraints are not met) to be followed by a
|
|
readjustment of the stack. So performance might be worse in such cases.</p>
|
|
|
|
<p>On x86 and x86-64 one register is reserved for indirect tail calls (e.g via a
|
|
function pointer). So there is one less register for integer argument
|
|
passing. For x86 this means 2 registers (if <tt>inreg</tt> parameter
|
|
attribute is used) and for x86-64 this means 5 register are used.</p>
|
|
|
|
</div>
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="x86">The X86 backend</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The X86 code generator lives in the <tt>lib/Target/X86</tt> directory. This
|
|
code generator is capable of targeting a variety of x86-32 and x86-64
|
|
processors, and includes support for ISA extensions such as MMX and SSE.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="x86_tt">X86 Target Triples supported</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The following are the known target triples that are supported by the X86
|
|
backend. This is not an exhaustive list, and it would be useful to add those
|
|
that people test.</p>
|
|
|
|
<ul>
|
|
<li><b>i686-pc-linux-gnu</b> — Linux</li>
|
|
|
|
<li><b>i386-unknown-freebsd5.3</b> — FreeBSD 5.3</li>
|
|
|
|
<li><b>i686-pc-cygwin</b> — Cygwin on Win32</li>
|
|
|
|
<li><b>i686-pc-mingw32</b> — MingW on Win32</li>
|
|
|
|
<li><b>i386-pc-mingw32msvc</b> — MingW crosscompiler on Linux</li>
|
|
|
|
<li><b>i686-apple-darwin*</b> — Apple Darwin on X86</li>
|
|
|
|
<li><b>x86_64-unknown-linux-gnu</b> — Linux</li>
|
|
</ul>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="x86_cc">X86 Calling Conventions supported</a>
|
|
</div>
|
|
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The following target-specific calling conventions are known to backend:</p>
|
|
|
|
<ul>
|
|
<li><b>x86_StdCall</b> — stdcall calling convention seen on Microsoft
|
|
Windows platform (CC ID = 64).</li>
|
|
|
|
<li><b>x86_FastCall</b> — fastcall calling convention seen on Microsoft
|
|
Windows platform (CC ID = 65).</li>
|
|
</ul>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="x86_memory">Representing X86 addressing modes in MachineInstrs</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The x86 has a very flexible way of accessing memory. It is capable of
|
|
forming memory addresses of the following expression directly in integer
|
|
instructions (which use ModR/M addressing):</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
Base + [1,2,4,8] * IndexReg + Disp32
|
|
</pre>
|
|
</div>
|
|
|
|
<p>In order to represent this, LLVM tracks no less than 4 operands for each
|
|
memory operand of this form. This means that the "load" form of
|
|
'<tt>mov</tt>' has the following <tt>MachineOperand</tt>s in this order:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
Index: 0 | 1 2 3 4
|
|
Meaning: DestReg, | BaseReg, Scale, IndexReg, Displacement
|
|
OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Stores, and all other instructions, treat the four memory operands in the
|
|
same way and in the same order.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="x86_memory">X86 address spaces supported</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>x86 has an experimental feature which provides
|
|
the ability to perform loads and stores to different address spaces
|
|
via the x86 segment registers. A segment override prefix byte on an
|
|
instruction causes the instruction's memory access to go to the specified
|
|
segment. LLVM address space 0 is the default address space, which includes
|
|
the stack, and any unqualified memory accesses in a program. Address spaces
|
|
1-255 are currently reserved for user-defined code. The GS-segment is
|
|
represented by address space 256, while the FS-segment is represented by
|
|
address space 257. Other x86 segments have yet to be allocated address space
|
|
numbers.</p>
|
|
|
|
<p>While these address spaces may seem similar to TLS via the
|
|
<tt>thread_local</tt> keyword, and often use the same underlying hardware,
|
|
there are some fundamental differences.</p>
|
|
|
|
<p>The <tt>thread_local</tt> keyword applies to global variables and
|
|
specifies that they are to be allocated in thread-local memory. There are
|
|
no type qualifiers involved, and these variables can be pointed to with
|
|
normal pointers and accessed with normal loads and stores.
|
|
The <tt>thread_local</tt> keyword is target-independent at the LLVM IR
|
|
level (though LLVM doesn't yet have implementations of it for some
|
|
configurations).<p>
|
|
|
|
<p>Special address spaces, in contrast, apply to static types. Every
|
|
load and store has a particular address space in its address operand type,
|
|
and this is what determines which address space is accessed.
|
|
LLVM ignores these special address space qualifiers on global variables,
|
|
and does not provide a way to directly allocate storage in them.
|
|
At the LLVM IR level, the behavior of these special address spaces depends
|
|
in part on the underlying OS or runtime environment, and they are specific
|
|
to x86 (and LLVM doesn't yet handle them correctly in some cases).</p>
|
|
|
|
<p>Some operating systems and runtime environments use (or may in the future
|
|
use) the FS/GS-segment registers for various low-level purposes, so care
|
|
should be taken when considering them.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="x86_names">Instruction naming</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>An instruction name consists of the base name, a default operand size, and a
|
|
a character per operand with an optional special size. For example:</p>
|
|
|
|
<div class="doc_code">
|
|
<pre>
|
|
ADD8rr -> add, 8-bit register, 8-bit register
|
|
IMUL16rmi -> imul, 16-bit register, 16-bit memory, 16-bit immediate
|
|
IMUL16rmi8 -> imul, 16-bit register, 16-bit memory, 8-bit immediate
|
|
MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory
|
|
</pre>
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<!-- ======================================================================= -->
|
|
<div class="doc_subsection">
|
|
<a name="ppc">The PowerPC backend</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The PowerPC code generator lives in the lib/Target/PowerPC directory. The
|
|
code generation is retargetable to several variations or <i>subtargets</i> of
|
|
the PowerPC ISA; including ppc32, ppc64 and altivec.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="ppc_abi">LLVM PowerPC ABI</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>LLVM follows the AIX PowerPC ABI, with two deviations. LLVM uses a PC
|
|
relative (PIC) or static addressing for accessing global values, so no TOC
|
|
(r2) is used. Second, r31 is used as a frame pointer to allow dynamic growth
|
|
of a stack frame. LLVM takes advantage of having no TOC to provide space to
|
|
save the frame pointer in the PowerPC linkage area of the caller frame.
|
|
Other details of PowerPC ABI can be found at <a href=
|
|
"http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Articles/32bitPowerPC.html"
|
|
>PowerPC ABI.</a> Note: This link describes the 32 bit ABI. The 64 bit ABI
|
|
is similar except space for GPRs are 8 bytes wide (not 4) and r13 is reserved
|
|
for system use.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="ppc_frame">Frame Layout</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The size of a PowerPC frame is usually fixed for the duration of a
|
|
function's invocation. Since the frame is fixed size, all references
|
|
into the frame can be accessed via fixed offsets from the stack pointer. The
|
|
exception to this is when dynamic alloca or variable sized arrays are
|
|
present, then a base pointer (r31) is used as a proxy for the stack pointer
|
|
and stack pointer is free to grow or shrink. A base pointer is also used if
|
|
llvm-gcc is not passed the -fomit-frame-pointer flag. The stack pointer is
|
|
always aligned to 16 bytes, so that space allocated for altivec vectors will
|
|
be properly aligned.</p>
|
|
|
|
<p>An invocation frame is laid out as follows (low memory at top);</p>
|
|
|
|
<table class="layout">
|
|
<tr>
|
|
<td>Linkage<br><br></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Parameter area<br><br></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Dynamic area<br><br></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Locals area<br><br></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Saved registers area<br><br></td>
|
|
</tr>
|
|
<tr style="border-style: none hidden none hidden;">
|
|
<td><br></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Previous Frame<br><br></td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>The <i>linkage</i> area is used by a callee to save special registers prior
|
|
to allocating its own frame. Only three entries are relevant to LLVM. The
|
|
first entry is the previous stack pointer (sp), aka link. This allows
|
|
probing tools like gdb or exception handlers to quickly scan the frames in
|
|
the stack. A function epilog can also use the link to pop the frame from the
|
|
stack. The third entry in the linkage area is used to save the return
|
|
address from the lr register. Finally, as mentioned above, the last entry is
|
|
used to save the previous frame pointer (r31.) The entries in the linkage
|
|
area are the size of a GPR, thus the linkage area is 24 bytes long in 32 bit
|
|
mode and 48 bytes in 64 bit mode.</p>
|
|
|
|
<p>32 bit linkage area</p>
|
|
|
|
<table class="layout">
|
|
<tr>
|
|
<td>0</td>
|
|
<td>Saved SP (r1)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>4</td>
|
|
<td>Saved CR</td>
|
|
</tr>
|
|
<tr>
|
|
<td>8</td>
|
|
<td>Saved LR</td>
|
|
</tr>
|
|
<tr>
|
|
<td>12</td>
|
|
<td>Reserved</td>
|
|
</tr>
|
|
<tr>
|
|
<td>16</td>
|
|
<td>Reserved</td>
|
|
</tr>
|
|
<tr>
|
|
<td>20</td>
|
|
<td>Saved FP (r31)</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>64 bit linkage area</p>
|
|
|
|
<table class="layout">
|
|
<tr>
|
|
<td>0</td>
|
|
<td>Saved SP (r1)</td>
|
|
</tr>
|
|
<tr>
|
|
<td>8</td>
|
|
<td>Saved CR</td>
|
|
</tr>
|
|
<tr>
|
|
<td>16</td>
|
|
<td>Saved LR</td>
|
|
</tr>
|
|
<tr>
|
|
<td>24</td>
|
|
<td>Reserved</td>
|
|
</tr>
|
|
<tr>
|
|
<td>32</td>
|
|
<td>Reserved</td>
|
|
</tr>
|
|
<tr>
|
|
<td>40</td>
|
|
<td>Saved FP (r31)</td>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>The <i>parameter area</i> is used to store arguments being passed to a callee
|
|
function. Following the PowerPC ABI, the first few arguments are actually
|
|
passed in registers, with the space in the parameter area unused. However,
|
|
if there are not enough registers or the callee is a thunk or vararg
|
|
function, these register arguments can be spilled into the parameter area.
|
|
Thus, the parameter area must be large enough to store all the parameters for
|
|
the largest call sequence made by the caller. The size must also be
|
|
minimally large enough to spill registers r3-r10. This allows callees blind
|
|
to the call signature, such as thunks and vararg functions, enough space to
|
|
cache the argument registers. Therefore, the parameter area is minimally 32
|
|
bytes (64 bytes in 64 bit mode.) Also note that since the parameter area is
|
|
a fixed offset from the top of the frame, that a callee can access its spilt
|
|
arguments using fixed offsets from the stack pointer (or base pointer.)</p>
|
|
|
|
<p>Combining the information about the linkage, parameter areas and alignment. A
|
|
stack frame is minimally 64 bytes in 32 bit mode and 128 bytes in 64 bit
|
|
mode.</p>
|
|
|
|
<p>The <i>dynamic area</i> starts out as size zero. If a function uses dynamic
|
|
alloca then space is added to the stack, the linkage and parameter areas are
|
|
shifted to top of stack, and the new space is available immediately below the
|
|
linkage and parameter areas. The cost of shifting the linkage and parameter
|
|
areas is minor since only the link value needs to be copied. The link value
|
|
can be easily fetched by adding the original frame size to the base pointer.
|
|
Note that allocations in the dynamic space need to observe 16 byte
|
|
alignment.</p>
|
|
|
|
<p>The <i>locals area</i> is where the llvm compiler reserves space for local
|
|
variables.</p>
|
|
|
|
<p>The <i>saved registers area</i> is where the llvm compiler spills callee
|
|
saved registers on entry to the callee.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="ppc_prolog">Prolog/Epilog</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p>The llvm prolog and epilog are the same as described in the PowerPC ABI, with
|
|
the following exceptions. Callee saved registers are spilled after the frame
|
|
is created. This allows the llvm epilog/prolog support to be common with
|
|
other targets. The base pointer callee saved register r31 is saved in the
|
|
TOC slot of linkage area. This simplifies allocation of space for the base
|
|
pointer and makes it convenient to locate programatically and during
|
|
debugging.</p>
|
|
|
|
</div>
|
|
|
|
<!-- _______________________________________________________________________ -->
|
|
<div class="doc_subsubsection">
|
|
<a name="ppc_dynamic">Dynamic Allocation</a>
|
|
</div>
|
|
|
|
<div class="doc_text">
|
|
|
|
<p><i>TODO - More to come.</i></p>
|
|
|
|
</div>
|
|
|
|
|
|
<!-- *********************************************************************** -->
|
|
<hr>
|
|
<address>
|
|
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
|
|
src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
|
|
<a href="http://validator.w3.org/check/referer"><img
|
|
src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
|
|
|
|
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
|
|
<a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
|
|
Last modified: $Date$
|
|
</address>
|
|
|
|
</body>
|
|
</html>
|