llvm dev - Jul 2012 - [LLVMdev] Possible issue with EXPANDING POST-RA PSEUDO INSTRS

Hal Finkel <hfinkel at anl.gov> writes:
>> Actually, we don't have any problem releasing tests.  We have done
so
>> before when sending patches.  The problem is the people we got the
>> tests from.  Some are from proprietary test suites, others are from
>> sensitive codes, etc.  It's often not up to us at all.
>
> I completely understand. Why don't we start by having you prepare LLVM
> IR files, and associated outputs, for x86_64 from your frontends only
> from open-source codes. As a first step, you could even just generate
> LLVM IR files for us from the codes in the LLVM test suite. We could
> setup a buildbot based on those files (which I believe would be easy to
> do), and then we can actively test trunk LLVM against those files.
I like this idea.  It'll work for C/C++ but not Fortran.  Since there is
no Fortran ABI one has to link with our Fortran compiler & libraries to
get an executable that actually works.

But let me think about this some more.  I would really like to expand
the LLVM testbase if we can.  It will be a long process since I'll have
to get all these tests approved for release.  I can't give a timeline on
that at all.  I think it will be a very gradual process.
 
> To be fair, the reason that my patch was not accepted was because it
> caused test-suite failures on x86. Does the patch work for you? 
I'm hopefully going to try it within the next few days.
> If it does, then maybe the situation has changed, and we should
> reconsider the status of the patch. The patch actually had two parts:
> the IR->DAG modifications and the changes to the ILP scheduling
> heuristic. Changes to the ILP scheduling heuristic may be required
> regardless of how or where the critical chain is relaxed.
Ok, I will take a look at that.
> Given that the patch caused test-suite failures on x86, I did not want
> to commit it as-is. 
Yes, I understand that.  But from the discussion I got the impression
that the patch wasn't wanted because ScheduleDAG is going to be
deprecated.  If that's not the case I will certainly work to get it
going!
> I would have loved if someone else had worked to
> diagnose and/or fix the remaining problems (which may have been
> scattered among different backends), but it is hard to ask people to do
> that for a feature that would be deprecated in six months time.
Yeah, I understand.  But for those of us working off releases it would
not be deprecated in six months.  That's probably moot now since 3.1 is
almost out the door but I think the patch will still be useful for us.

Believe me, I would really like to be able to work off trunk but I have
to convince a lot of people here that that is possible.  Starting with
myself.  :)

                                -Dave

Hi Dave,
>>> Actually, we don't have any problem releasing tests.  We have
done so
>>> before when sending patches.  The problem is the people we got the
>>> tests from.  Some are from proprietary test suites, others are from
>>> sensitive codes, etc.  It's often not up to us at all.
>>
>> I completely understand. Why don't we start by having you prepare
LLVM
>> IR files, and associated outputs, for x86_64 from your frontends only
>> from open-source codes. As a first step, you could even just generate
>> LLVM IR files for us from the codes in the LLVM test suite. We could
>> setup a buildbot based on those files (which I believe would be easy to
>> do), and then we can actively test trunk LLVM against those files.
>
> I like this idea.  It'll work for C/C++ but not Fortran.  Since there
is
> no Fortran ABI one has to link with our Fortran compiler&  libraries to
> get an executable that actually works.
if you provide a bunch of IR for Fortran, it can at least be checked that
the optimizers/codegen don't crash on it.

Ciao, Duncan.

Duncan Sands <baldrick at free.fr> writes:
>> I like this idea.  It'll work for C/C++ but not Fortran.  Since
there is
>> no Fortran ABI one has to link with our Fortran compiler& 
libraries to
>> get an executable that actually works.
>
> if you provide a bunch of IR for Fortran, it can at least be checked that
> the optimizers/codegen don't crash on it.
Yes, absolutely.  There's certainly value there.

                             -Dave

On Fri, 11 May 2012 10:26:41 -0500
<dag at cray.com> wrote:
> Hal Finkel <hfinkel at anl.gov> writes:
> 
> >> Actually, we don't have any problem releasing tests.  We have
done
> >> so before when sending patches.  The problem is the people we got
> >> the tests from.  Some are from proprietary test suites, others are
> >> from sensitive codes, etc.  It's often not up to us at all.
> >
> > I completely understand. Why don't we start by having you prepare
> > LLVM IR files, and associated outputs, for x86_64 from your
> > frontends only from open-source codes. As a first step, you could
> > even just generate LLVM IR files for us from the codes in the LLVM
> > test suite. We could setup a buildbot based on those files (which I
> > believe would be easy to do), and then we can actively test trunk
> > LLVM against those files.
> 
> I like this idea.  It'll work for C/C++ but not Fortran.  Since there
> is no Fortran ABI one has to link with our Fortran compiler &
> libraries to get an executable that actually works.
> 
> But let me think about this some more.  I would really like to expand
> the LLVM testbase if we can.  It will be a long process since I'll
> have to get all these tests approved for release.  I can't give a
> timeline on that at all.  I think it will be a very gradual process.
Out of curiosity, what is your current thinking on this?

 -Hal
>  
> > To be fair, the reason that my patch was not accepted was because it
> > caused test-suite failures on x86. Does the patch work for you? 
> 
> I'm hopefully going to try it within the next few days.
> 
> > If it does, then maybe the situation has changed, and we should
> > reconsider the status of the patch. The patch actually had two
> > parts: the IR->DAG modifications and the changes to the ILP
> > scheduling heuristic. Changes to the ILP scheduling heuristic may
> > be required regardless of how or where the critical chain is
> > relaxed.
> 
> Ok, I will take a look at that.
> 
> > Given that the patch caused test-suite failures on x86, I did not
> > want to commit it as-is. 
> 
> Yes, I understand that.  But from the discussion I got the impression
> that the patch wasn't wanted because ScheduleDAG is going to be
> deprecated.  If that's not the case I will certainly work to get it
> going!
> 
> > I would have loved if someone else had worked to
> > diagnose and/or fix the remaining problems (which may have been
> > scattered among different backends), but it is hard to ask people
> > to do that for a feature that would be deprecated in six months
> > time.
> 
> Yeah, I understand.  But for those of us working off releases it would
> not be deprecated in six months.  That's probably moot now since 3.1
> is almost out the door but I think the patch will still be useful for
> us.
> 
> Believe me, I would really like to be able to work off trunk but I
> have to convince a lot of people here that that is possible.
> Starting with myself.  :)
> 
>                                 -Dave


-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory

Hello everyone, 

  I am running into an obscure issue with ExpandPostRA. Does anyone
recognizes the following:

The pass replaces a real copy with a "transfer" instruction:

********** EXPANDING POST-RA PSEUDO INSTRS **********
********** Function: main
real copy:   %R15<def> = COPY %R4, %D2<imp-use,kill>,
%D7<imp-use,kill>,
%D7<imp-def>
replaced by: %R15<def> = TFR %R4, %D7<imp-def>

The R4 is a subreg of D2 double register (basically R0:R1==D0; R4:R5==D2
etc.). After this copy D2 is dead, and is marked as such.
Register allocator did not mark R4 as <kill>, and when ExpandPostRA copies
operands, it loses the live range marker.

My questions - is this a known issue? ...and should R4 has been marked as
<kill> in the original instruction?

...and yes... I am on branch 3.1, not on trunk, so if it has been fixed by
now, it would be great to know.

Thanks a lot.

Sergei

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum.

Hal Finkel <hfinkel at anl.gov> writes:
> On Fri, 11 May 2012 10:26:41 -0500
> <dag at cray.com> wrote:
>
>> Hal Finkel <hfinkel at anl.gov> writes:
>> 
>> >> Actually, we don't have any problem releasing tests.  We
have done
>> >> so before when sending patches.  The problem is the people we
got
>> >> the tests from.  Some are from proprietary test suites, others
are
>> >> from sensitive codes, etc.  It's often not up to us at
all.
>> >
>> > I completely understand. Why don't we start by having you
prepare
>> > LLVM IR files, and associated outputs, for x86_64 from your
>> > frontends only from open-source codes. As a first step, you could
>> > even just generate LLVM IR files for us from the codes in the LLVM
>> > test suite. We could setup a buildbot based on those files (which
I
>> > believe would be easy to do), and then we can actively test trunk
>> > LLVM against those files.
>> 
>> I like this idea.  It'll work for C/C++ but not Fortran.  Since
there
>> is no Fortran ABI one has to link with our Fortran compiler &
>> libraries to get an executable that actually works.
>> 
>> But let me think about this some more.  I would really like to expand
>> the LLVM testbase if we can.  It will be a long process since I'll
>> have to get all these tests approved for release.  I can't give a
>> timeline on that at all.  I think it will be a very gradual process.
>
> Out of curiosity, what is your current thinking on this?
I would still like to do it.  I haven't had any conversations with
management yet, however.  It will take some time to get everything in
order.

                               -Dave