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
Sergei Larin
2012-Jul-08 22:42 UTC
[LLVMdev] Possible issue with EXPANDING POST-RA PSEUDO INSTRS
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