Hi, I would like to ping these patches. [0/4] https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611286.html [1/4] https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611287.html [2/4] https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611288.html [3/4] https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611289.html [4/4] https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611290.html
Any sugguestions for the code functionality/style or to make it easy for review, please point out, thanks in advance! BR, Jeff (Jiufu) Jiufu Guo via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > Hi, > > Gental ping these patches: > https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611286.html > > BR, > Jeff (Jiufu) > > > Jiufu Guo <guoji...@linux.ibm.com> writes: > >> Hi, >> >> For a given constant, it would be profitable if we can use 2 insns to build. >> This patch enables more constants building through 2 insns: one is "li or >> lis", >> another is 'rldicl, rldicr or rldic'. >> Through checking and analyzing the characters of the insns "li/lis;rldicX", >> all the possible constant values are considered by this patch. >> >> Previously, a patch is posted, but it is too large. >> https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601276.html >> As suggested, I split it into this series. >> >> Considering the functionality and size, 4 patches are split as below: >> 1. Support the constants which can be built by "li;rotldi" >> Both positive and negative values from insn "li" are analyzed. >> 2. Support the constants which can be built by "lis;rotldi" >> We only need to analyze the negative value from "lis". >> And this patch uses more code to check leading 1s and tailing 0s from >> "lis". >> 3. Support the constants which can be built by "li/lis;rldicl/rldicr": >> Leverage the APIs defined/analyzed in patches 1 and 2, >> this patch checks the characters for the mask of "rldicl/rldicr" >> to support more constants. >> 4. Support the constants which can be built by "li/lis;rldic": >> The mask of "rldic" is relatively complicated, it is analyzed in this >> patch to support more constants. >> >> BR, >> Jeff (Jiufu)
