On 07/19/2018 06:55 AM, Tamar Christina wrote: >>> >>> What's the purpose of including auto-host in params-list and >>> params-options? It seems like you're putting a property of the target >>> (guard size) into the wrong place (auto-host.h). >>> >> >> The reason for this is because there's a test gcc.dg/params/blocksort-part.c >> that uses these params-options to generate test cases to perform parameter >> validation. However because now the params.def file can contain a CPP >> macro these would then fail. >> >> CPP is already called to create params-options and params-list so the easiest >> way to fix this test was just to include auto-host which would get it the >> values >> from configure. >> >> This test is probably not needed anymore after my second patch series as >> parameters are validated by the front-end now, so they can never go out of >> range. Right, but I don't immediately see a way to avoid the test. ie, it just walks down everything in params.options and except for a couple exceptional values the test gets run.
I wonder if all this is an indication that having CPP constants in the options isn't going to work well as we're mixing the distinction between host/target. >> >>> It's also a bit unclear to me why this is necessary at all. Are we >>> planning to support both the 4k and 64k guards? My goal (once the >>> guard was configurable) was never for supporting multiple sizes on a >>> target but instead to allow experimentation to find the right default. >>> > > Having talked to people I believe we do need to support both 4k and 64k > guards. > For the Linux/Glibc world it wouldn't matter much, either 4 or 64k would do, > though Glibc has settled on 64k pages. > > However other systems like (open/free)BSD or musl based systems do not want > 64k pages but want 4k ones. So we're ending up having to support both as a > compromise. Understood. Thanks for verifying. I wonder if we could just bury this entirely in the aarch64 config files and not expose the default into params.def? jeff
