Draft: Fix MULTI_ALLOC build

At some point the multi-alloc build started failing, this fixed it.

FYI @graven

added Build bug fix labels

this suggests that the MULTI_ALLOC build is not being build as part of the CI -- so it would be good to make sure it will be...

added 1 commit

• 0d585ccb - Change to a reinterpret_cast

Compare with previous version

added 1 commit

• 3e38f735 - Add build and physics efficiency run with multi-alloc

Compare with previous version

added 1 commit

• 2adfabd1 - Add build and physics efficiency run with multi-alloc

Compare with previous version

It's been added to the CI for the manual pipeline and passes, as can be seen here:

https://gitlab.cern.ch/lhcb/Allen/-/jobs/12160442#L80

and here:

https://gitlab.cern.ch/lhcb/Allen/-/jobs/12160479

@dcampora, any additional comments? Otherwise I'd like to pass this to the shifter.

We should decide on a strategy for these sorts of tests. As it stands, MULTI_ALLOC will only be compiled for CUDA Debug and run on BsPhiPhi data in the efficiency configuration (no repetitions, single thread, run validation). I would also add a MULTI_ALLOC compilation on both CPU and HIP, and a run on CPU.

Whatever the decision we take is, we should adopt it across all options we test (not for this MR). For instance, SYNCHRONOUS=ON, GENERATE_SEQUENCE=OFF, etc.

It would also be nice to extend the physics efficiency reference test over all of these results. However, for that the CI needs to evolve, since there would be an overlap with the current efficiency files, as the option MULTI_ALLOC isn't used to find a different ref file.

assigned to @raaij and unassigned @dcampora

assigned to @msaur

@raaij Can this be tested or a further development is expected?

mentioned in issue Moore#263 (closed)

mentioned in issue Moore#265 (closed)

assigned to @jbaptist and unassigned @msaur

I suggest to make this a draft and rebase after !547 (merged)

marked this merge request as draft

unassigned @jbaptist

mentioned in merge request !489 (merged)

mentioned in issue Moore#272 (closed)

mentioned in issue Moore#273 (closed)