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

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 :slight_smile:

Thanks for the help!

-Tanya

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

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? :slight_smile:

-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? :slight_smile:

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

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.

It's the front-end what done it.

Ciao,

Duncan.

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

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!

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

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.

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.

I applied the patch that you sent:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080519/062879.html

-Tanya