<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Jim,<br>
<br>
Thanks as always for the good suggestions.<br>
<br>
I will definitely look into ways to incorporate your ideas from
the ARM port in order to make this pass more generally palatable
to all.<br>
<br>
When this first version is working I want to think about the
cleanest way to do this.<br>
<br>
Reed<br>
<br>
On 05/15/2013 11:02 AM, Jim Grosbach wrote:<br>
</div>
<blockquote
cite="mid:6F7B4629-E33B-434B-AA49-A125B20AD9AA@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Hi Reed,
<div><br>
</div>
<div>Glad to see the discussion getting back going again. Thanks.
Let’s see if we can work through <br>
<div>
<div>On May 15, 2013, at 10:02 AM, reed kotler <<a
moz-do-not-send="true" href="mailto:rkotler@mips.com">rkotler@mips.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="letter-spacing: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">On 05/15/2013 07:14 AM,
Rafael Espíndola wrote:<br>
<blockquote type="cite">
<blockquote type="cite">I probably air too much of what
I'm doing on the list as far as design and<br>
my attempt is never to hide such things. I really
could not have imagined<br>
such a big discussion about generating some tiny stubs
. It only came up<br>
during the issue of the APP/NO_APP wrappers.<br>
</blockquote>
I still think you are doing this wrong and it will be
harder to<br>
implement it correctly once you have this in. IMHO the
only thing<br>
needing special treatment for the stubs in the backend
would be<br>
calling convention. Other than that they would be
regular mips16 or<br>
mips32 *IL* functions. Mixing mips16 and mip32 should
not be that<br>
different from mixing thumb and arm.<br>
</blockquote>
This is a separate module pass. There is nothing being
done here except solving this problem<br>
so it's easy to modify, delete or replace in the future..<br>
<br>
</div>
</blockquote>
OK.<br>
<br>
<blockquote type="cite">
<div style="letter-spacing: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">I have filed a bug
already against myself at Mips to look at this issue of
using special calling conventions. I did a special calling
convention already for the return helpers but these are
more involved. There are special issues here not normally
covered by a simple calling convention. If you look at the
code in assureFPCallStub you will see that the way the
helper even calls the real function depends on whether the
function returns float, double, single or double complex
and then the final return is different too. The next patch
after this, which you have not seen yet, relies on some
special gas tricks that. This is just the way it was
designed for gcc but it's very efficient the way they work<br>
so that was the reason.<br>
</div>
</blockquote>
<div><br>
</div>
<div>GCC is a useful example, to be sure, but the compiler
architectures are so different that what’s a good design fit
for one does not imply it’s a good fit for the other. For
example, inline asm for GCC is just a textual blob of
output. For LLVM it’s a much different thing due to the
integrated assembler and MC layers. What GCC does isn’t a
very compelling argument.</div>
<br>
<blockquote type="cite">
<div style="letter-spacing: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">I'm with you on making
things better and simpler all the time. It's not always
practical to hit the<br>
final goal on the first try.<br>
</div>
</blockquote>
<br>
<div>Yep. Iterative development is great. We just want to make
sure that the incremental steps actually are moving in the
direction of the eventual goal and won’t get in the way when
the time comes. Making sure we don’t incur more technical
debt than we need to, basically.</div>
<br>
<blockquote type="cite">
<div style="letter-spacing: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;"><br>
<blockquote type="cite">But you are correct, I don't have
big objections to you guys<br>
implementing this in the way you think is best, *as long
as it stays<br>
local to mips*. In particular, two things that came up
in this<br>
discussion that really don't want to see in trunk are:<br>
<br>
* the ability for the compiler to tell if an inline asm
is compiler<br>
generated or human written. (the APP/NO_APP discussion).
I am ok with<br>
avoiding printing them, as long as we avoid for all
inline asm (by not<br>
printing it at all for mips target for example).<br>
</blockquote>
This APP/NO_APP would be covered in a separate patch and
is only for cosmetic purposes.</div>
</blockquote>
<blockquote type="cite">
<div style="letter-spacing: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;"><br>
I was not asking for the compiler to be able to tell this.<br>
<br>
I want be able to have a function attribute which tells
asmprinter to not emit those.<br>
This could be usable by the compiler itself or if we
*chose* to make it general, by a user.<br>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>I’m strongly opposed to any target independent patch
which makes a distinction about “compiler generated” or
“user generated” inline assembly blocks. If you can do this
purely in code in the lib/Target/Mips tree, go for it. If it
touches anywhere else, that’s a problem. This is a
non-starter.</div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div style="letter-spacing: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">When GCC creates these
stubs, they look like normal compiler code (no APP/NO_APP)
markers<br>
and without this ability LLVM is going to add these
markers after each line.<br>
<br>
There is no functional difference in the code but they
look ugly to me and it makes it harder to<br>
read them.</div>
</blockquote>
<blockquote type="cite">
<div style="letter-spacing: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;"><br>
This is not really that important but I think we should
not have them here because they serve no<br>
purpose other than to make the stub harder to read.</div>
</blockquote>
<div><br>
</div>
<div>That’s the compiler telling you that you’re using a
mechanism not intended for this sort of purpose.</div>
<div><br>
</div>
<div>There are a few things going on here, so I’ll try to
break them apart a bit.</div>
<div><br>
</div>
<div>1) Generally speaking, how to get interworking stubs into
the code.</div>
<div><br>
</div>
<div>Interworking is a tricky thing to be sure. ARM has the
same sort of problems with Thumb vs. ARM code. On Darwin, we
solve this by having the linker insert the stub functions
when necessary and fixing up the interworking calls to do
the right thing. If that’s possible for you, I’d encourage
investigating the option, as it’s worked really well for us.
There’s complications when you have historical ABI, of
course. If you really do have to do this in the compiler, we
end up with:</div>
<div><br>
</div>
<div>2) How to get a specific asm sequence emitted by the
compiler into a function.</div>
<div><br>
</div>
<div>This is what pseudo-instructions, target intrinsics,
custom lowerings, etc. are for. Depending on which layers of
the back end you want the operation to be opaque or
transparent to, you can choose which mechanism to use. As
I’ve said before, have a look at ARM. It does a *lot* of
this sort of thing. The closest analog to inline asm is an
MC-level pseudo, which is a black-box to the compiler all
the way through the backend until lowering the MC right
before .s/.o emission. Switching to use something like that
instead would likely be very straightforward and will play
much more cleanly with the rest of the compiler. It’ll also
get rid of the APP/NO_APP markers for you.</div>
<div><br>
</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>-Jim</div>
<br>
<br>
<blockquote type="cite">
<div style="letter-spacing: normal; orphans: auto;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">
<blockquote type="cite">* the extension of the section
attribute to be an arbitrary string<br>
passed to the assembler or the addition of section
related attributes<br>
(i.e.,<span class="Apple-converted-space"> </span><a
moz-do-not-send="true" href="http://llvm.org/pr15788">llvm.org/pr15788</a><span
class="Apple-converted-space"> </span>should be closed
as wontfix).<br>
</blockquote>
I did not need anything special here as I thought I would
originally.<br>
I was able to use the builtin function attributes that
LLVM supports to get the desired result.<br>
<br>
<br>
Thanks for taking the time to respond in such detail.<br>
<br>
Reed<br>
<br>
<blockquote type="cite">Cheers,<br>
Rafael</blockquote>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>