Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aarch64 backend generates invalid asm: conditional branch out of range #6878

Closed
vicuna opened this issue May 26, 2015 · 11 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link

commented May 26, 2015

Original bug ID: 6878
Reporter: Richard Jones
Assigned to: @mshinwell
Status: closed (set by @xavierleroy on 2017-02-16T14:14:11Z)
Resolution: fixed
Priority: normal
Severity: minor
Platform: aarch64
OS: Linux
Version: 4.02.1
Target version: 4.02.2+dev / +rc1
Fixed in version: 4.02.2+dev / +rc1
Category: back end (clambda to assembly)
Monitored by: @gasche jmeber

Bug description

When compiling very large (especially autogenerated) .ml files on aarch64, we sometimes see this error:

  • /usr/bin/ocamlopt.opt -c -g -safe-string -g -inline 1000 -w @1..49-4-9-33-41-44 -o parser.cmx parser.ml
    /tmp/camlasm50dee1.s: Assembler messages:
    /tmp/camlasm50dee1.s:3024: Error: conditional branch out of range
    /tmp/camlasm50dee1.s:87479: Error: conditional branch out of range
    File "parser.ml", line 1:
    Error: Assembler error, input left in file /tmp/camlasm50dee1.s

This has been observed when compiling menhir and alt-ergo. It is 100%
reproducible.

Steps to reproduce

Compile menhir on aarch64 with OCaml 4.02.1.

Additional information

Downstream Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=1224815

File attachments

@vicuna

This comment has been minimized.

Copy link
Author

commented May 26, 2015

Comment author: @mshinwell

I am looking at this

@vicuna

This comment has been minimized.

Copy link
Author

commented May 26, 2015

Comment author: @mshinwell

The problem is that a conditional branch is out of range within a very large function. The problem doesn't just affect tbz.

LLVM deals with this by transforming:

tbz L1

into:

tbnz L2
b L1
L2:

(see http://llvm.org/docs/doxygen/html/AArch64BranchRelaxation_8cpp_source.html)

Unfortunately the AArch64 backend in OCaml doesn't currently measure the size of instructions emitted (unlike the 32-bit backend). We could maybe alter the backend to do the measuring, and then emit the alternative code sequence when required.

Alternatively, as a temporary measure, we could always emit the alternative code sequence for 4.02.2 and later fix this properly in trunk.

Maybe it is possible to use the sequences that we use in the 32-bit backend on 64-bit; I haven't checked the reference manual yet.

Xavier, what do you think?

@vicuna

This comment has been minimized.

Copy link
Author

commented May 26, 2015

Comment author: Richard Jones

Can't be done by being clever with assembler macros? I couldn't quite work out the syntax, but one thing I tried to do was:

--- camlasm50dee1.s 2015-05-26 09:54:09.751488754 +0100
+++ camltest.s 2015-05-26 15:25:02.273846192 +0100
@@ -3021,7 +3021,13 @@
movz x21, #1, lsl #0
str x21, [x0, #24]
ldr x22, [x0, #16]

  •    .if .L635 - . > 1000
    
    tbz x22, #0, .L635
  •    .else
    
  • tbnz x22, #0, 1f
  •    b .L635
    

+1:

  •    .endif
    
    asr x21, x22, #1
    adr x16, .L2408
    add x16, x16, x21, lsl #2

which gives the error "non-constant expression in ".if" statement".

@vicuna

This comment has been minimized.

Copy link
Author

commented May 26, 2015

Comment author: Richard Jones

(Also as well as not working, my test is backwards)

@vicuna

This comment has been minimized.

Copy link
Author

commented May 27, 2015

Comment author: @mshinwell

I don't think this will be able to be done with assembler macros, since the distances between labels will vary according to which instructions are there. (This leads on to the whole "relaxation" thing.)

@vicuna

This comment has been minimized.

Copy link
Author

commented May 28, 2015

Comment author: @mshinwell

I am writing a fix for this

@vicuna

This comment has been minimized.

Copy link
Author

commented May 29, 2015

Comment author: @mshinwell

Proposed patch (which still requires some polishing up, but should be close to what is required) in this branch, which is based on 4.02:

https://github.com/mshinwell/ocaml/tree/pr6878

We have a report that Menhir successfully compiles on a real AArch64 machine with this patch.

@vicuna

This comment has been minimized.

Copy link
Author

commented May 29, 2015

Comment author: @gasche

In case anyone is curious, the right github incantation to see the patch as a whole appears to be:

https://github.com/ocaml/ocaml/compare/4.02...mshinwell:pr6878?diff=unified&name=pr6878&w=0#files_bucket

@vicuna

This comment has been minimized.

Copy link
Author

commented Jun 4, 2015

Comment author: @mshinwell

I've now polished this patch up, and I did some more testing on Power and ARM. I will do even more testing after comments.

@vicuna

This comment has been minimized.

Copy link
Author

commented Jun 10, 2015

Comment author: @mshinwell

Fixed in 4.02 (rev 16168).

@vicuna

This comment has been minimized.

Copy link
Author

commented Jun 10, 2015

Comment author: Richard Jones

Can confirm that the final upstream 4.02 branch resolves the problem on real hardware. Thanks Mark!

@vicuna vicuna closed this Feb 16, 2017

@vicuna vicuna added the back-end label Mar 14, 2019

@vicuna vicuna added this to the 4.02.2 milestone Mar 14, 2019

@vicuna vicuna added the bug label Mar 20, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.