ASSERT_EXPR during SIMPLE_IPA_PASS and LTO
Hi, I am working on an analysis that is able to determine some static information about a specific variable. At the moment, I would like to avoid much of the transformation by taking advantage of other GCC's passes. So, I can imagine something like, create an ASSERT_EXPR and let other passes change the CFG, and remove dead code, fold constants, etc. At the moment I am only prototyping it, and so I have created a SIMPLE_IPA_PASS during LTO that finds the variables of interest and then creates an ASSERT_EXPR which contains the static information of interest. This looks to be working somewhat correctly. When I print the functions' gimple everything looks ok. The pass doesn't fail even if I use the TODO_verify_all flag at the end of the SIMPLE_IPA_PASS. However, the transformation triggers a segfault during fixup_cfg and I am unsure what can be the case. My questions are: 1. Is it possible to insert new ASSERT_EXPR during LTO and have other tree passes transform the function based on this? 2. How complex can the ASSERT_EXPR be? I can see that it must be a COND expr, by which it can be EQ_EXPR, NE_EXPR, LT_EXPR... and others. But what if I need to express something like a bitmask to guarantee that certain bits are zero? Could I have a complicated ASSERT_EXPR where COND is ASSERT_EXPR (a & 0xff == 0)? Or should I break it down? temp = a & 0xff; ASSERT_EXPR (temp == 0); 3. Any other advice? Thanks!
ARM Cortex-R5F Support
Hi, I'm looking at working on Cortex-R5F support for RTEMS, but it seems as if latest GCC supports the Cortex-R5. This R5 has implicit FPU support which would make it really R5F. The ARM reference page on this core (https://developer.arm.com/Processors/Cortex-R5) specifies that the FPU is optional. I see that the FPU support can probably be disabled using the nofp option to achieve Cortex-R5 support, but I was wondering why this is handled differently from the Cortex-R4[F] support since that is broken out into two different CPU entries in gcc/config/arm/arm-cpus.in. It appears that R7 and R8 are handled the same way as R5. Is the R4/R4F just the legacy way of handling this and R5/7/8 are the new way? Thanks, Kinsey
Re: ASSERT_EXPR during SIMPLE_IPA_PASS and LTO
On Tue, Mar 1, 2022 at 3:37 PM Erick Ochoa via Gcc wrote: > > Hi, > > I am working on an analysis that is able to determine some static > information about a specific variable. At the moment, I would like to avoid > much of the transformation by taking advantage of other GCC's passes. So, I > can imagine something like, create an ASSERT_EXPR and let other passes > change the CFG, and remove dead code, fold constants, etc. > > At the moment I am only prototyping it, and so I have created a > SIMPLE_IPA_PASS during LTO that finds the variables of interest and then > creates an ASSERT_EXPR which contains the static information of interest. > > This looks to be working somewhat correctly. When I print the functions' > gimple everything looks ok. The pass doesn't fail even if I use the > TODO_verify_all flag at the end of the SIMPLE_IPA_PASS. However, the > transformation triggers a segfault during fixup_cfg and I am unsure what > can be the case. > > My questions are: > 1. Is it possible to insert new ASSERT_EXPR during LTO and have other tree > passes transform the function based on this? ASSERT_EXPR is something only used internally by the VRP pass, it cannot be used elsewhere and is not expected by most of the compiler. > 2. How complex can the ASSERT_EXPR be? I can see that it must be a COND > expr, by which it can be EQ_EXPR, NE_EXPR, LT_EXPR... and others. But what > if I need to express something like a bitmask to guarantee that certain > bits are zero? Could I have a complicated ASSERT_EXPR where COND is > ASSERT_EXPR (a & 0xff == 0)? > Or should I break it down? > temp = a & 0xff; > ASSERT_EXPR (temp == 0); > 3. Any other advice? > > Thanks!
