Hi, On 26 August 2017 at 18:10, Pinski, Andrew <andrew.pin...@cavium.com> wrote: >> However there might be pushback from upstream maintainers as this makes the >> structure bigger >> by adding a field. This could have implications for memory usage of the >> compiler. > > I looked into the structure, adding this field is not going to make the > structure bigger for either ILP32 or LP64 targets. If you want, you use > bit-fields; there is one bool already there which means you can fit 8 bits in > the same area as currently taken up by that one.
Yes. I should have checked the mem_attrs structure. This does have at least a byte left unlike some other tightly packed structures (gimple and some tree structures in gcc). Thanks, Kugan >> Alternatively, we maybe able to get this info from dwarf info when we >> compile with -g ? > > I doubt you can. He wants to know if an instruction is a spill location. > The location of a variable might be recorded in -g (if it was an user > variable) but not that does present the data for all temps being spilled. > > I think the patch is actually a good one in general just needs some cleanup. > > As for these comments: >>> For example, GCC calls `output_asm_insn' directly from the `define_insn' >>> definition in the aarch64.md file without an insn object(`output_asm_insn' >>> calls `output_asm_operand_names'). >>> This occurs in "*cb<optab><mode>1" and >>> "*aarch64_fcvt<su_optab><GPF:mode><GPI:mode>2_mult". > > Spills in GCC will always be via the mov* patterns (they are special). > Now really *aarch64_fcvt<su_optab><GPF:mode><GPI:mode>2_mult should be fixed > for a different reason; it does unneeded work. The fix would be something > like (untested): > { > operands[2] = GEN_INT (aarch64_fpconst_pow_of_2 (operands[2])); > return "fcvtz<su>\t%<GPI:w>0, %<GPF:s>1, %2"; > } > > Thanks, > Andrew > > > -----Original Message----- > From: linaro-toolchain [mailto:linaro-toolchain-boun...@lists.linaro.org] On > Behalf Of Kugan Vivekanandarajah > Sent: Saturday, August 26, 2017 12:40 AM > To: Renato Golin <renato.go...@linaro.org> > Cc: Jim Wilson <jim.wil...@linaro.org>; hpc-sig-de...@linaro.org; Linaro > Toolchain <linaro-toolchain@lists.linaro.org> > Subject: Re: [hpc-sig-devel] GCC extensions for `hcqc' > > Hi, > > On 26 August 2017 at 04:04, Renato Golin <renato.go...@linaro.org> wrote: >> +linaro-toolchain, hoping to get more eyes into it. >> >> cheers, >> --renato >> >> On 25 August 2017 at 17:59, Masaki Arai <masaki.a...@linaro.org> wrote: >>> Hi, >>> >>> I extended GCC 7.1(or GCC 7.2) for `hcqc'. >>> I would be grateful if you could give me a comment about whether this >>> extension is acceptable and whether this extension should be pushed >>> upstream. > > I think this is a useful info. However there might be pushback from upstream > maintainers as this makes the structure bigger by adding a field. This could > have implications for memory usage of the compiler. > Alternatively, we maybe able to get this info from dwarf info when we compile > with -g ? Jim may have some input here (cc ing him). > > Thanks, > Kugan > >>> >>> The extended GCC's output using the option ` -fverbose-asm' is as >>> follows: >>> >>> ldr w0, [x29,48] // tmp433, j(8-byte Folded Spill) >>> ^^^^^^^^^^^^^^^^^^^ This >>> code shows that this instruction accesses a memory area for spill >>> codes. >>> I made the following changes to GCC 7.1(or GCC 7.2). >>> The related files are under `hcqc/patch/gcc-7.1.0-add'. >>> >>> (1) rtl.h >>> >>> I added flag information to `struct mem_attrs' that means whether it >>> is a spill memory area or not. >>> >>> + >>> + /* True if the MEM is for spill. */ >>> + bool for_spill_p; >>> >>> Also, I added an access macro for this additional field. >>> >>> + /* For a MEM rtx, true if its MEM is for spill. */ #define >>> + MEM_FOR_SPILL_P(RTX) (get_mem_attrs (RTX)->for_spill_p) >>> + >>> >>> (2) emit-rtl.c >>> >>> I added a code to turn on flags for spill memory area in function >>> `set_mem_attrs_for_spill'. >>> >>> + attrs.for_spill_p = true; >>> >>> (3) final.c >>> >>> I added code to print that information in function >>> `output_asm_operand_names' >>> if the memory is a spill memory area, >>> >>> + >>> + if (MEM_P (op) && MEM_FOR_SPILL_P (op)) >>> + { >>> + HOST_WIDE_INT size = MEM_SIZE (op); >>> + fprintf (asm_out_file, " (" HOST_WIDE_INT_PRINT_DEC "-byte >>> + Folded >>> Spill)", size); >>> + } >>> >>> The above changes are implemented similarly as Clang/LLVM. >>> Unfortunately, it is difficult for GCC to print the above "(?-byte >>> Folded Spill)" >>> for memory access instructions only in the same manner as Clang/LLVM. >>> The reason is that GCC executes the above `output_asm_operand_names' >>> even in situations where any instruction object(insn) does not exist >>> when outputting assembly code. >>> For example, GCC calls `output_asm_insn' directly from the `define_insn' >>> definition in the aarch64.md file without an insn object(`output_asm_insn' >>> calls `output_asm_operand_names'). >>> This occurs in "*cb<optab><mode>1" and >>> "*aarch64_fcvt<su_optab><GPF:mode><GPI:mode>2_mult". >>> >>> From this fact, `hcqc' extracts and accumulates memory access >>> instructions from the assembly code with the comment "(?-byte Folded >>> Spill)". >>> >>> The above extensions are commonly available on almost any architecture. >>> Also, these extensions do not affect the execution of the resulting >>> assembly code since additional outputs are only in comments. >>> >>> Best regards, >>> -- >>> -------------------------------------- >>> Masaki Arai >>> >> _______________________________________________ >> linaro-toolchain mailing list >> linaro-toolchain@lists.linaro.org >> https://lists.linaro.org/mailman/listinfo/linaro-toolchain > _______________________________________________ > linaro-toolchain mailing list > linaro-toolchain@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/linaro-toolchain _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain