This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Implementation in NEON of non uniform address jumps

Parents
  • Note: This was originally posted on 16th July 2012 at http://forums.arm.com

    It is reasonably unlikely that the compiler is doing something it shouldn't be at "-O3"; the more likely scenario is that:

    1. for inline assembly, you aren't describing the required/expected side-effects, so the compiler is [correctly] assuming it can optimize the code out (e.g. if your inline Neon code is writing all its results back to memory, are you declaring memory as having been modified, and/or the assembly as being "volatile"?).

    2. for C code, you are relying on something which the C standard does require to be invariant, and thus can legally be optimized out (e.g. relying on the values of variables which fall out of scope, or relying on the explicit number of memory accesses for things not declared as volatile).

    hth
    s.
Reply
  • Note: This was originally posted on 16th July 2012 at http://forums.arm.com

    It is reasonably unlikely that the compiler is doing something it shouldn't be at "-O3"; the more likely scenario is that:

    1. for inline assembly, you aren't describing the required/expected side-effects, so the compiler is [correctly] assuming it can optimize the code out (e.g. if your inline Neon code is writing all its results back to memory, are you declaring memory as having been modified, and/or the assembly as being "volatile"?).

    2. for C code, you are relying on something which the C standard does require to be invariant, and thus can legally be optimized out (e.g. relying on the values of variables which fall out of scope, or relying on the explicit number of memory accesses for things not declared as volatile).

    hth
    s.
Children
No data