llvm dev - Jun 2008 - [LLVMdev] Status of the 2.3 release - volunteers needed.

Many of you are probably wondering about the status of the 2.3  
release. Unfortunately, this release has been very difficult and the  
list of regressions very high. The list has finally dwindled down to  
the following regressions:

Linux/x86:
SingleSource/Benchmarks/CoyoteBench/fftbench [ JIT Codegen, JIT]
MultiSource/Applications/minisat/minisat [CBE]

Darwin/x86:
External/SPEC/CINT2006/403.gcc/403.gcc [CBE, but works on mainline..]

Darwin/ppc:
SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ]
External/SPEC/CINT2006/403.gcc/403.gcc [ CBE]

If anyone would like to volunteer to help track down these issues, it  
would be very much appreciated. You can grab the source tarballs  
(http://llvm.org/prereleases/2.3/) or check out the release branch.

The release will be stalled until the regressions can be either fixed  
or some other decision is reached.

Thanks,
Tanya
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080602/8d3adcec/attachment.html>

Tanya Lattner wrote:
> Many of you are probably wondering about the status of the 2.3
> release. Unfortunately, this release has been very difficult and the
> list of regressions very high. The list has finally dwindled down to
> the following regressions:
>
> Linux/x86:
> SingleSource/Benchmarks/CoyoteBench/fftbench [ JIT Codegen, JIT]

Increasing ulimit to 230 Mb (from 200Mb) makes fftbench/JIT pass on
mainline.
Maybe JIT should have a higher ulimit because it needs to keep the
bytecode in memory too?
> MultiSource/Applications/minisat/minisat [CBE]
CBE didn't fail for me with the prerelease package, instead JIT failed
on minisat.

Do you want me to retry with llvm 2.3 from the release branch?
>
> Darwin/x86:
> External/SPEC/CINT2006/403.gcc/403.gcc [CBE, but works on mainline..]
>
> Darwin/ppc:
> SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ]
> External/SPEC/CINT2006/403.gcc/403.gcc [ CBE]
Don't have a Mac, so I can't help here.

Best regards,
--Edwin

>> Many of you are probably wondering about the status of the 2.3
>> release. Unfortunately, this release has been very difficult and the
>> list of regressions very high. The list has finally dwindled down to
>> the following regressions:
>>
>> Linux/x86:
>> SingleSource/Benchmarks/CoyoteBench/fftbench [ JIT Codegen, JIT]
>
>
> Increasing ulimit to 230 Mb (from 200Mb) makes fftbench/JIT pass on
> mainline.
> Maybe JIT should have a higher ulimit because it needs to keep the
> bytecode in memory too?
Thank you! Anton committed a patch to reduce the testcase size, so I think 
this should be fixed now.
>> MultiSource/Applications/minisat/minisat [CBE]
>
> CBE didn't fail for me with the prerelease package, instead JIT failed
> on minisat.
>
> Do you want me to retry with llvm 2.3 from the release branch?

No, thats ok. I think someone has narrowed down the issue:
http://llvm.org/bugs/show_bug.cgi?id=2407

The JIT does fail on minisat, but it is not a regression. So while it is a 
bug, its not critical for this release. If you want to investigate it, 
please feel free :)

Thanks for the help!

-Tanya

On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote:
> Many of you are probably wondering about the status of the 2.3  
> release. Unfortunately, this release has been very difficult and the  
> list of regressions very high. The list has finally dwindled down to  
> the following regressions:
>
...
> Darwin/ppc:
> SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ]
For my test run, it looks like the type "llvmUInt128" isn't
defined.
Is this this the error that you're seeing?
> External/SPEC/CINT2006/403.gcc/403.gcc [ CBE]
>
-bw

On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote:
> Darwin/ppc:
> SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ]
>
 From what I can see comparing 2.3 with TOT, the "cexp" function is  
declared like this in 2.3:

	declare i128 @cexp({double, double}* byval) nounwind

It used to be this:

	declare void @cexp({double, double}* noalias sret, {double, double}*  
byval) nounwind

Does this difference look familiar to someone? :-)

-bw

> > Darwin/ppc:
> > SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ]
> >
>  From what I can see comparing 2.3 with TOT, the "cexp" function
is
> declared like this in 2.3:
> 
> 	declare i128 @cexp({double, double}* byval) nounwind
> 
> It used to be this:
> 
> 	declare void @cexp({double, double}* noalias sret, {double, double}*  
> byval) nounwind
> 
> Does this difference look familiar to someone? :-)
It looks like this is due to the ABI work: the struct is now being
returned as a scalar (HandleAggregateResultAsScalar), i.e. in registers.  Is
this wrong for Darwin/ppc?

D.

>  From what I can see comparing 2.3 with TOT, the "cexp" function
is
> declared like this in 2.3:
> 
> 	declare i128 @cexp({double, double}* byval) nounwind
> 
> It used to be this:
> 
> 	declare void @cexp({double, double}* noalias sret, {double, double}*  
> byval) nounwind
The promotion from a void function with an sret argument to a function
returning multiple values is probably performed by StructRetPromotion (some
grepping around the source suggests that no other pass actually looks at sret
parameters).

However, I'm not sure what replaces that struct of two doubles by a single
i128. I think ScalarReplAggregrates is capable of doing such packing, but it
only operates on local variables, not return types AFAIK.

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080604/54d96c98/attachment.sig>

On Jun 4, 2008, at 12:54 AM, Bill Wendling wrote:
> On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote:
>
>> Many of you are probably wondering about the status of the 2.3
>> release. Unfortunately, this release has been very difficult and the
>> list of regressions very high. The list has finally dwindled down to
>> the following regressions:
>>
> ...
>> Darwin/ppc:
>> SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ]
>
> For my test run, it looks like the type "llvmUInt128" isn't
defined.
> Is this this the error that you're seeing?
>
Yes.

-Tanya
>> External/SPEC/CINT2006/403.gcc/403.gcc [ CBE]
>>
>
> -bw
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Jun 4, 2008, at 2:33 AM, Bill Wendling wrote:
> On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote:
>
>> Darwin/ppc:
>> SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ]
>>
> From what I can see comparing 2.3 with TOT, the "cexp" function
is
> declared like this in 2.3:
>
> 	declare i128 @cexp({double, double}* byval) nounwind
>
> It used to be this:
>
> 	declare void @cexp({double, double}* noalias sret, {double, double}*
> byval) nounwind
>
> Does this difference look familiar to someone? :-)
This is an ABI fix, and it's the correct thing to do.  Since GCC  
doesn't support i128 when compiling for 32-bit processors, this can't  
reasonably be fixed, and certainly won't be for LLVM 2.3.

-Chris

Ok, I have good news! Thanks for the help!

On Jun 2, 2008, at 11:11 PM, Tanya Lattner wrote:
> Many of you are probably wondering about the status of the 2.3  
> release. Unfortunately, this release has been very difficult and  
> the list of regressions very high. The list has finally dwindled  
> down to the following regressions:
>
> Linux/x86:
> SingleSource/Benchmarks/CoyoteBench/fftbench [ JIT Codegen, JIT]
> MultiSource/Applications/minisat/minisat [CBE]
>
Both of these are now fixed!
> Darwin/x86:
> External/SPEC/CINT2006/403.gcc/403.gcc [CBE, but works on mainline..]
>
This is a gcc bug, so we are ignoring it for the release.
> Darwin/ppc:
> SingleSource/Benchmarks/CoyoteBench/fftbench [ CBE ]
> External/SPEC/CINT2006/403.gcc/403.gcc [ CBE]
>
fftbench - GCC doesn't support i128 when compiling for 32-bit  
processors, so no fix for this.
403.gcc - same as mentioned above, gcc bug.

So, I need to rerun all the tests and package things up. Chris is  
working on the release notes. Hopefully we can have this out by the  
end of the week.

-Tanya

> If anyone would like to volunteer to help track down these issues,  
> it would be very much appreciated. You can grab the source tarballs  
> (http://llvm.org/prereleases/2.3/) or check out the release branch.
>
> The release will be stalled until the regressions can be either  
> fixed or some other decision is reached.
>
> Thanks,
> Tanya
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080604/8b99bf89/attachment.html>

Tanya Lattner wrote:
> So, I need to rerun all the tests and package things up. Chris is 
> working on the release notes. Hopefully we can have this out by the end 
> of the week.
Did you apply my patch to get 2.3 to build in Visual Studio 'out of the
box'? ... I never saw any more replies and I'm
not subscribed to llvm-commits, so I don't know if it went in.

m.