<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 17, 2013 at 8:25 PM, reed kotler <span dir="ltr"><<a href="mailto:rkotler@mips.com" target="_blank">rkotler@mips.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>HI Daniel,<br>
<br>
We need the Multisource/UnitTests to test all the Mips32/Mips16
floating point interoperability.<br>
<br>
This is a real crazy quilt design that evolved over time that I
inherited from gcc. I actually came up with a better way to do all
of that that does not have any of this complexity but my
management insisted that I first implement the gcc scheme.<br>
<br>
If the compiler can see all the code then it can cheat and not
generate the stubs.<br>
<br>
Basically Mips32 code does not know anything about Mips16 code.<br>
<br>
There are only issues when there are values usually passed or
returned in floating point registers accord to the Mips32 ABI.<br>
<br>
When in Mips16 mode, you can't execute any floating point
instructions or access floating point registers.<br>
<br>
In that mode there is more or less a soft float with run time
support written in code compiled in Mips32 mode.<br>
<br>
Anyway there are lots of cases to test and pic and static are much
different in some areas too.<br>
<br>
When you compile Mips16 code that returns floating point values or
has floating point parameters that are normally passed in floating
point registers OR that calls external functions of unknown type
(Mips32 or Mips16), then there are various stubs or predefined
library functions that must be created/called.<br>
<br>
Anyway.. I need multiple physical source files to test this
completely.</div></div></blockquote><div><br></div><div>Okay, I'm fine with that. Feel free to commit.</div><div><br></div><div> - Daniel</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><span class="HOEnZb"><font color="#888888"><br>
Reed</font></span><div><div class="h5"><br>
<br>
<br>
<br>
On 06/17/2013 10:59 AM, Daniel Dunbar wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">Hi Reed,
<div><br>
</div>
<div>Does MultiSource/UnitTests really make sense? Generally we
want most of the code in the test suite to be cross platform,
so I would hope that any architecture specific tests are
limited to checking very specific features, and are well
suited to the directory-full-of-single-file-tests model.<br>
</div>
<div><br>
</div>
<div>Other than that, the patch looks fine to me.</div>
<div><br>
</div>
<div> - Daniel</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sat, Jun 8, 2013 at 10:47 PM, reed
kotler <span dir="ltr"><<a href="mailto:rkotler@mips.com" target="_blank">rkotler@mips.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This patch
is to allow areas in SingleSource and MultiSource for Mips
specific tests to be added to UnitTests in those areas.<br>
<br>
Some example tests are included in the patch.<br>
<br>
I have tested with x86 and Mips test suites and for Mips
with lnt.<br>
<br>
Am rerunning all tests this weekend.<br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>