<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 04/01/2013 12:31 PM, Chandler
Carruth wrote:<br>
</div>
<blockquote
cite="mid:CAGCO0KiCruNhWH+5S=FspcQ=Le14pdgyJG1Opd3xnWejFTB-_g@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_extra">On Thu, Mar 28, 2013 at 12:22 PM, Nadav
Rotem <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:nrotem@apple.com" target="_blank"
class="cremed">nrotem@apple.com</a>></span> wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">IMHO the
right way to handle target function attributes is to
re-initialize the target machine and TTI for every
function (if the attributes changed). Do you have another
solution in mind ?</blockquote>
</div>
<br>
I don't really understand this.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">TargetMachine and TTI may be quite
expensive to initialize. Doing so for each (sometimes tiny)
function processed doesn't make a lot of sense to me.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Wouldn't it be better to design a
TargetMachine (and TTI, or other passes that are similar)
which provides context-sensitive answers? You could imagine
this being a wrapper which delegates to one of two real TM and
TTI implementations based on a mode switch.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra" style="">Alternatively, we could look
at partitioning functions into two modules, and then bring up
the infrastructure once per module.</div>
<div class="gmail_extra" style="">
<br>
</div>
<div class="gmail_extra" style="">I would personally choose
between these based on how much shared functionality there
would be in the TM and TTI between the two.</div>
</div>
</blockquote>
For changing subtargets, i.e. mips16 to mips32 on a per function
basis, I only have one copy of all that is needed for both mips16
and mips32.<br>
<br>
What I do is I have two versions of the instruction selection pass
(mips16 and mips32) and a controller pass which is used to reset
parts of target machine when needed (ptrs to target lowering,
register info, frame lowering which in the case of mips16 / mips32
are different derived classes).<br>
<br>
If the run machine function is called in the mips16 instruction
selection pass, it returns immediately if it's in mips32 mode and
similarly in the mips32 instruction selection pass.<br>
<br>
The one hole is this immutable pass for basic target transform info
which should be a function pass. This can also be done so that maybe
only at most two copies of this pass are present and the information
is reset when the subtarget changes.<br>
<br>
I'm attaching the current state of the patch in case you want to see
how I'm doing this now.<br>
<br>
Many things can be handled with just options to the normal setup but
something which differs as much as mips16 and mips32 or thumb1 and
arm need a subtarget reset.<br>
<br>
</body>
</html>