| Message ID | 20210721092810.66070-1-kito.cheng@sifive.com |
|---|---|
| Headers | show |
| Series | New target hook TARGET_COMPUTE_MULTILIB and implementation for RISC-V | expand |
ping On Wed, Jul 21, 2021 at 5:28 PM Kito Cheng <kito.cheng@sifive.com> wrote: > > This patch set allow target to use customized multi-lib mechanism rather than the built-in > multi-lib mechanism. > > The motivation of this patch is RISC-V might have very complicated multi-lib re-use > rule*, which is hard to maintain and use current multi-lib scripts, > we even hit the "argument list too long" error when we tried to add more > multi-lib reuse rule. > > * Here is an example for RISC-V multi-lib rules: > https://gist.github.com/kito-cheng/0289cd42d9a756382e5afeb77b42b73b > > V2 Changes: > - NO changes for first patch(TARGET_COMPUTE_MULTILIB part) since first version. > - Handle option other than -march and -mabi for riscv_compute_multilib. > >
On Thu, 29 Jul 2021 11:44:09 PDT (-0700), gcc-patches@gcc.gnu.org wrote: > ping > > On Wed, Jul 21, 2021 at 5:28 PM Kito Cheng <kito.cheng@sifive.com> wrote: >> >> This patch set allow target to use customized multi-lib mechanism rather than the built-in >> multi-lib mechanism. >> >> The motivation of this patch is RISC-V might have very complicated multi-lib re-use >> rule*, which is hard to maintain and use current multi-lib scripts, >> we even hit the "argument list too long" error when we tried to add more >> multi-lib reuse rule. >> >> * Here is an example for RISC-V multi-lib rules: >> https://gist.github.com/kito-cheng/0289cd42d9a756382e5afeb77b42b73b >> >> V2 Changes: >> - NO changes for first patch(TARGET_COMPUTE_MULTILIB part) since first version. >> - Handle option other than -march and -mabi for riscv_compute_multilib. This generally LGTM, but I think it's the sort of thing that should be looked at by a global reviewer. There's a bit of a policy decision being made here in that this allows external hooks during the build process. I'm fine with this, as it's just the multilib list, those are really specific to a specific toolchain distribution, and there's never going to be a way to catalog all the interested cases for the embedded toolchains. I'm still not comfortable calling that a review, though, as these things are subtle and I don't always have the same bar for external bits that the rest of the GCC folks do.
Got Jim's review and approval before, but apparently we missed this last year, rebase and committed to trunk. On Fri, Jul 30, 2021 at 3:01 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Thu, 29 Jul 2021 11:44:09 PDT (-0700), gcc-patches@gcc.gnu.org wrote: > > ping > > > > On Wed, Jul 21, 2021 at 5:28 PM Kito Cheng <kito.cheng@sifive.com> wrote: > >> > >> This patch set allow target to use customized multi-lib mechanism rather than the built-in > >> multi-lib mechanism. > >> > >> The motivation of this patch is RISC-V might have very complicated multi-lib re-use > >> rule*, which is hard to maintain and use current multi-lib scripts, > >> we even hit the "argument list too long" error when we tried to add more > >> multi-lib reuse rule. > >> > >> * Here is an example for RISC-V multi-lib rules: > >> https://gist.github.com/kito-cheng/0289cd42d9a756382e5afeb77b42b73b > >> > >> V2 Changes: > >> - NO changes for first patch(TARGET_COMPUTE_MULTILIB part) since first version. > >> - Handle option other than -march and -mabi for riscv_compute_multilib. > > This generally LGTM, but I think it's the sort of thing that should be > looked at by a global reviewer. There's a bit of a policy decision > being made here in that this allows external hooks during the build > process. > > I'm fine with this, as it's just the multilib list, those are really > specific to a specific toolchain distribution, and there's never going > to be a way to catalog all the interested cases for the embedded > toolchains. I'm still not comfortable calling that a review, though, as > these things are subtle and I don't always have the same bar for > external bits that the rest of the GCC folks do.