Too long compile time with some array size

[dalance]

I changed array size of the following line.

https://github.com/dalance/veryl/blob/eff1afcbdca883e6938d232852e3f10944001682/crates/formatter/src/aligner.rs#L105

Some values cause compiler hang in release mode.
In debug mode, all value is OK.

For example,

aligns: [Align; 1], // OK
aligns: [Align; 2], // NG
aligns: [Align; 3], // OK
aligns: [Align; 4], // OK

In 1..20, 2 and 6 to 12 is NG. The others is OK.
I tried to change the array to Vec. It is NG.

aligns: Vec<Align>,

I couldn't reduce the testcase size.
So I write the reproduce procedure.

$ git clone https://github.com/dalance/veryl
$ git checkout eff1afcbdca883e6938d232852e3f10944001682
$ cargo build --release  # OK
$ sed -i 's/Align; 5/Align; 2/g' crates/formatter/src/aligner.rs
$ cargo build --release  # NG

Meta

rustc --version --verbose:

rustc 1.66.0 (69f9c33d7 2022-12-12)
binary: rustc
commit-hash: 69f9c33d71c871fc16ac445211281c6e7a340943
commit-date: 2022-12-12
host: x86_64-unknown-linux-gnu
release: 1.66.0
LLVM version: 15.0.2

[dalance]

Hang is not correct. Actually too long time.

• aligns: [Align; 5],

   Compiling veryl-formatter v0.1.3 (/home/hatta/work/repos/veryl/crates/formatter)
    Finished release [optimized] target(s) in 1.57s

• aligns: [Align; 2],

   Compiling veryl-formatter v0.1.3 (/home/hatta/work/repos/veryl/crates/formatter)
    Finished release [optimized] target(s) in 1m 26s

[fmease]

@rustbot label T-compiler I-compiletime E-needs-mcve

[clubby789]

A rough profile seems to show most of the time is spent in LLVM_lto_optimize

[dalance]

Disabling LTO by codegen-units = 1 seems to resolve the issue.

[clubby789]

@rustbot label +A-llvm +A-lto

[bwmf2]

A mcve of 513 SLOC. It builds very fast for 2, 3, 4, 5 and 6 but for 1 and from 7 to 32 it's longer.

[KisaragiEffective]

Reproducible for size of 1 to 8 via bwmf2's mcve.

Attempts

I've made some attempts with bwmf2's mcve:

No any extra affect

• Removing unused parameter from Aligner::space
• Removing receiver mutability from Aligner::space
• Using same const value for both Aligner definition and <Aligner as VerylWaker>::veryl_token

Positive effect

• Adding #[inline(always)], #[inline] to Aligner::space
• Removing call to Aligner::space

[bwmf2]

Can enough information be extracted as is or must it be minimized even more?

I checked again and from 7 to 32 and 1 are slow and the other are fast. I will incorporate the feedback, thanks.

A bit different but it should be the same issue. The next step will be to remove some Boxes.