[RFC] Removing BBVectorize?

Hi Everyone,

I propose that we remove BBVectorize from trunk. Here's why:

- It never made it from "interesting experiment" to "production quality" (it is not part of any in-tree optimization pipeline).

- We now have an SLP vectorizer that we do use in production, had have for some time.

- BBVectorize otherwise needs refactoring, and the implementation has lots of cutoffs (because the underlying algorithm is asymptotically expensive).

- It has bugs (the way it tracks anti-dependencies from calls, for example, is broken: PR20600).

In short, while BBVectorize was useful when it was added, it is unclear to me whether or not its continuing presence outweighs the ongoing maintenance costs and resulting user confusion (I still occasionally see users turning it on when they likely would be happier with the SLP vectorizer instead).

So, if you're using it and would like it to stay, please speak up! Also, BBVectorize has an API. Is anyone using it?

Thanks again (and happy Thanksgiving),
Hal

Dear Hal,

this probably makes sense. Happy thanksgiving!

Cheers,
Tobias

Hal-
A few months back when I ran spec cpu2006 (int) I did see some small uplifts for a few benchmarks using -vectorize-slp-aggressive (bb vec) but also ran into a failure with one of the bms. May not be reason enough to keep it around, though.

-dibyendu

Hal Finkel wrote:

Hi Everyone,

I propose that we remove BBVectorize from trunk. Here's why:

  - It never made it from "interesting experiment" to "production quality" (it is not part of any in-tree optimization pipeline).

  - We now have an SLP vectorizer that we do use in production, had have for some time.

What's the approach of the BB vectorizer vs. the SLP vectorizer? What's the value in the BB vectorizer if it were all cleaned up, etc.?

Hi Everyone,

I propose that we remove BBVectorize from trunk. Here's why:

- It never made it from "interesting experiment" to "production quality" (it is not part of any in-tree optimization pipeline).

- We now have an SLP vectorizer that we do use in production, had have for some time.

- BBVectorize otherwise needs refactoring, and the implementation has lots of cutoffs (because the underlying algorithm is asymptotically expensive).

- It has bugs (the way it tracks anti-dependencies from calls, for example, is broken: PR20600).

In short, while BBVectorize was useful when it was added, it is unclear to me whether or not its continuing presence outweighs the ongoing maintenance costs and resulting user confusion (I still occasionally see users turning it on when they likely would be happier with the SLP vectorizer instead).

So, if you're using it and would like it to stay, please speak up! Also, BBVectorize has an API. Is anyone using it?

Thanks again (and happy Thanksgiving),
Hal

Hi Hal,

I agree with your proposal.

The BB vectorizer was the first LLVM vectorizer and it helped to improve the LLVM vector code generation. Many of the good ideas in the BB vectorizer were later adopted by the SLP-vectorizer. Thank you for developing the BB vectorizer!

Nadav

+1

--renato