[PATCH} [Review Request] MCJIT PIC support for x86-64

[Daniel Dunbar]

On Aug 16, 2013, at 16:34, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote:

  What we need for MCJIT is the ability to run a single test with a variety
of command line options and have the XFAIL status be specific to the
command line options used.



This goes beyond just running the tests once with JIT and once with MCJIT.
 Within MCJIT I’d like to exercise a variety of code model and relocation
model combinations as well as remote execution.  Remote execution is a
particular problem because only a few of the tests make sense to run that
way at the moment.


Ok. Having a nice solution for that sounds like more than just the SUBTEST
feature.

One question: for the time being, would it be possible to exercise some of
those paths with gtest unit tests, which do support parameterization?

 - Daniel

Within those constraints, I’d be happy to adopt whatever solution is
available.



-Andy



*From:* daniel.dunbar at gmail.com
[mailto:daniel.dunbar at gmail.com<daniel.dunbar at gmail.com>]
*On Behalf Of *Daniel Dunbar
*Sent:* Friday, August 16, 2013 3:44 PM
*To:* Eli Bendersky
*Cc:* Kaylor, Andrew; Commit Messages and Patches for LLVM
*Subject:* Re: [PATCH} [Review Request] MCJIT PIC support for x86-64



On Fri, Aug 16, 2013 at 2:56 PM, Eli Bendersky <eliben at google.com> wrote:

 On Fri, Aug 16, 2013 at 11:40 AM, Kaylor, Andrew <andrew.kaylor at intel.com>
wrote:

 Hi Eli,



Thanks for the suggestions regarding documentation.  I’ll see what I can
put together.  I believe I still have the diagrams you referred to, and I
can put together something more to describe the control flow.



BTW, I wanted to let you know that your old blog posts describing the PIC
relocation model were extremely helpful as I was putting this patch
together.  Yours was the clearest description of PIC handling that I was
able to find.



Glad it helped! I'll have to reread them myself before I review your patch
;-)





Also, I meant to ask what ever happened to the lit subtest patch that you
submitted about a year and a half ago.  As far as I can tell it was never
committed, but I couldn’t tell why not.  The “new” tests I’m introducing
are just duplications of other tests with variations in invocation
arguments.  It would be nice to be able to simplify that ExecutionEngine
testing tree.



I recall the patch was very close to being done, and Daniel Dunbar was OK
with it, but somehow in the last stages of reviewing we both got
distracted. The real problem is that the last versions of the patch were
mailed directly to Daniel from... my old @intel.com address. So unless
Daniel (CCd) still has them lying somewhere, I fear the patch is lost :-/
Not that it was a big deal, and it would have to be tweaked in light of the
recent additions to FileCheck anyhow. I still believe it's a good thing to
have and will be happy to help reviewing a new patch if anyone is willing
to take it over.



I've attached the last version I got from you. I think if we were going to
revisit adding this I might want to take a slightly different approach in
light of some other directions I would like to take lit. Primarily I would
like to consider lifting the subtest handling up to the generic lit layer
instead of specific to the ShTest format. There are other test formats I am
hoping to develop that could make use of some kind of explicit subtest
support. This would also solve one of the outstanding issues with the patch
which was how to compute an overall test result status in the presence of
XFAILs, XPASS, etc.



I would also like to know how support for parameterized tests overlaps with
this. For MCJIT specifically it sounds like what is really desired is some
support for parameterized tests so that all the JIT tests can be run with
and without the MCJIT. That feature has come up in the past as well, and
could be really useful in cases where we want to, e.g., run a test for each
configured target.



 - Daniel





Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130817/070e5199/attachment.html>