Re: [PATCH] xtensa: fix PR target/91880

[augustine.sterl...@gmail.com]

On Tue, Sep 24, 2019 at 5:41 PM Max Filippov  wrote:
>
> Xtensa hwloop_optimize segfaults when zero overhead loop is about to be
> inserted as the first instruction of the function.
> Insert zero overhead loop instruction into new basic block before the
> loop when basic block that precedes the loop is empty.
>
> 2019-09-24  Max Filippov  
> gcc/
> * config/xtensa/xtensa.c (hwloop_optimize): Insert zero overhead
> loop instruction into new basic block before the loop when basic
> block that precedes the loop is empty.
>
> gcc/testsuite/
> * gcc.target/xtensa/pr91880.c: New test case.
> * gcc.target/xtensa/xtensa.exp: New test suite.
> ---
>  gcc/config/xtensa/xtensa.c |  5 ++--
>  gcc/testsuite/gcc.target/xtensa/pr91880.c  | 10 
>  gcc/testsuite/gcc.target/xtensa/xtensa.exp | 41 
> ++
>  3 files changed, 54 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/xtensa/pr91880.c
>  create mode 100644 gcc/testsuite/gcc.target/xtensa/xtensa.exp

Approved. Thanks.

Re: [PATCH 30/30] Changes to xtensa

[augustine.sterl...@gmail.com]

On Tue, Jun 25, 2019 at 1:41 PM  wrote:
>
> From: Aaron Sawdey 
>
> * config/xtensa/xtensa.md (movmemsi): Change name to cpymemsi.
> ---
>  gcc/config/xtensa/xtensa.md | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

OK for xtensa.

Re: [PATCH] xtensa: fix PR target/90922

[augustine.sterl...@gmail.com]

On Tue, Jun 18, 2019 at 2:27 PM Max Filippov  wrote:
>
> Stack pointer adjustment code in prologue missed a case of no
> callee-saved registers and a stack frame size bigger than 128 bytes.
> Handle that case.
>
> This fixes the following gcc tests with call0 ABI:
>   gcc.c-torture/execute/stdarg-2.c
>   gcc.dg/torture/pr55882.c
>   gcc.dg/torture/pr57569.c

Approved, please apply.

Re: [PATCH] gcc: move assemble_start_function / assemble_end_function to output_mi_thunk

[augustine.sterl...@gmail.com]

On Tue, May 14, 2019 at 10:28 AM Max Filippov  wrote:
>
> Let backends call assemble_start_function after they have generated
> thunk function body so that a constant pool could be output if it is
> required. This may help backends to avoid implementing custom constant
> loading code specifically for the MI thunk and reuse existing
> functionality.

Approved for xtensa.

Re: [PATCH] PR target/86814

[augustine.sterl...@gmail.com]

On Sun, Dec 30, 2018 at 1:06 AM Max Filippov  wrote:
>
> Xtensa architecture is not affected by speculation.
>
> gcc/
> 2018-12-30  Max Filippov  
>
> * config/xtensa/xtensa.c (TARGET_HAVE_SPECULATION_SAFE_VALUE):
> Define to speculation_safe_value_not_needed.

Approved.

Re: [PATCH v2] gcc: xtensa: don't force PIC for uclinux target

[augustine.sterl...@gmail.com]

On Mon, Nov 5, 2018 at 11:07 AM Max Filippov  wrote:

> xtensa-uclinux uses bFLT executable file format that cannot relocate
> fields representing offsets from data to code. C++ objects built as PIC
> use offsets to encode FDE structures. As a result C++ exception handling
> doesn't work correctly on xtensa-uclinux. Don't use PIC by default on
> xtensa-uclinux.
>
> gcc/
> 2018-11-04  Max Filippov  
>
> * config/xtensa/uclinux.h (XTENSA_ALWAYS_PIC): Change to 0.
>

Approved.

Re: [PATCH v2] gcc: xtensa: fix NAND code in xtensa_expand_atomic

[augustine.sterl...@gmail.com]

On Tue, Sep 4, 2018 at 9:42 AM Max Filippov  wrote:

> NAND is ~(a1 & a2), but xtensa_expand_atomic does ~a1 & a2.
> That fixes libatomic tests atomic-op-{1,2}.
>
> gcc/
> 2018-09-04  Max Filippov  
>
> * config/xtensa/xtensa.c (xtensa_expand_atomic): Reorder AND and
> XOR operations in NAND case.
>

Approved.

Re: [PATCH] xtensa: fix PR target/65416

[augustine.sterl...@gmail.com]

On Mon, Jun 18, 2018 at 3:10 PM, Max Filippov  wrote:

> gcc/
> 2018-06-17  Max Filippov  
>
> * config/xtensa/xtensa.md (UNSPEC_FRAME_BLOCKAGE): New unspec
> constant.
> (allocate_stack, frame_blockage, *frame_blockage): New patterns.
>

This is OK.

Re: [PATCH] libgcc: xtensa: fix build with -mtext-section-literals

[augustine.sterl...@gmail.com]

On Tue, Jan 30, 2018 at 8:02 PM, Max Filippov  wrote:
>
> libgcc/
> 2018-01-31  Max Filippov  
>
> * config/xtensa/ieee754-df.S (__adddf3_aux): Add
> .literal_position directive.
> * config/xtensa/ieee754-sf.S (__addsf3_aux): Likewise.


This is fine, but when did it stop working, and why isn't there a test
that would catch it?

Re: [PATCH] libgcc: xtensa: fix NaN return from add/sub/mul/div helpers

[augustine.sterl...@gmail.com]

On Tue, Jan 23, 2018 at 9:55 AM, Max Filippov  wrote:
> libgcc/
> 2018-01-22  Max Filippov  
>
> * config/xtensa/ieee754-df.S (__addsf3, __subsf3, __mulsf3)
> (__divsf3): Make NaN return value quiet.
> * config/xtensa/ieee754-sf.S (__adddf3, __subdf3, __muldf3)
> (__divdf3): Make NaN return value quiet.

This is fine. Please apply.

Re: [PATCH] gcc: xtensa: enable address sanitizer

[augustine.sterl...@gmail.com]

On Mon, Dec 4, 2017 at 1:28 PM, Max Filippov  wrote:
> gcc/
> 2017-12-04  Max Filippov  
>
> * config/xtensa/xtensa.c (xtensa_asan_shadow_offset): New
> function.
> (TARGET_ASAN_SHADOW_OFFSET): New macro definition.
> * config/xtensa/xtensa.h (FRAME_GROWS_DOWNWARD): Set to 1 if
> ASAN is enabled.

This is OK.

Re: [PATCH] xtensa: fix PR target/82181

[augustine.sterl...@gmail.com]

On Mon, Sep 11, 2017 at 2:16 PM, Max Filippov  wrote:
> 2017-09-11  Max Filippov  
> gcc/
> * config/xtensa/xtensa.c (xtensa_mem_offset): Check that both
> words of E_DImode object are reachable by xtensa_uimm8x4 access.

Approved. Please apply.

Re: [PATCH] gcc: xtensa: fix fprintf format specifiers

[augustine.sterl...@gmail.com]

On Mon, May 29, 2017 at 4:11 AM, Max Filippov  wrote:
> HOST_WIDE_INT may not be long as assumed in print_operand and
> xtensa_emit_call. Use HOST_WIDE_INT_PRINT_DEC/HOST_WIDE_INT_PRINT_HEX
> format strings instead of %ld/0x%lx. This fixes incorrect assembly code
> generation by the compiler running on armhf host.

This is ok.

Re: [PATCH] gcc: xtensa: fix unused parameter warning

[augustine.sterl...@gmail.com]

On Mon, May 29, 2017 at 4:11 AM, Max Filippov  wrote:
> 2017-05-28  Max Filippov  
> gcc/
> * config/xtensa/xtensa.c (xtensa_initial_elimination_offset):
> Mark 'to' argument with ATTRIBUTE_UNUSED.

This is ok.

Re: [RFC 2/5] gcc: xtensa: make configuration dynamic

[augustine.sterl...@gmail.com]

On Mon, May 22, 2017 at 2:09 PM, Max Filippov  wrote:
> Now that XCHAL_* macros don't have to be preprocessor constants add
> include/xtensa-dynconfig.h that defines them as fields of a structure
> returned from the xtensa_get_config function.
> Define that structure and fill it with default parameter values
> specified in the include/xtensa-config.h.
> Define reusable function xtensa_load_config that tries to load
> configuration and return an address of an exported object from it.
> Define the function xtensa_get_config that uses xtensa_load_config to
> get structure xtensa_config, either dynamically configured or the
> default.
>
> 2017-05-22  Max Filippov  
> gcc/
> * Makefile.in (PLUGIN_HEADERS): Add include/xtensa-dynconfig.h.
> * config.gcc (xtensa*-*-*): Add xtensa-config.o to extra_objs.
> * gcc/config/xtensa/t-xtensa (xtensa-config.o): New rule.
> * gcc/config/xtensa/xtensa-config.c: New file.
> * gcc/config/xtensa/xtensa.h (xtensa-config.h): Replace #include
> with xtensa-dynconfig.h
> (XCHAL_HAVE_MUL32_HIGH, XCHAL_HAVE_RELEASE_SYNC,
>  XCHAL_HAVE_S32C1I, XCHAL_HAVE_THREADPTR,
>  XCHAL_HAVE_FP_POSTINC): Drop definitions.

This almost certainly should go through the normal gcc plugin
mechanism instead of the hand-rolled one you have here.

https://gcc.gnu.org/onlinedocs/gccint/Plugins.html#Plugins

If there is a reason it can't (and I'm not sufficiently familiar with
the issues here), then you need to ensure that the various protections
enforced by the normal plugin mechanism is used--and someone more
knowledgeable than me needs to review it.

Please note that by using a plugin mechanism, there are licensing
issues that come into play, that are different from the usual
licensing issues. I would be absolutely sure that you all are OK with
how the runtime exception applies to this new situation.

Re: [RFC 1/5] gcc: xtensa: allow XCHAL_* macros to be non-constant

[augustine.sterl...@gmail.com]

On Mon, May 22, 2017 at 2:09 PM, Max Filippov  wrote:
> XCHAL_* macros from the xtensa-config.h are used in a number of places
> that require them to be preprocessor constants. Rewrite these places so
> that non-constant XCHAL_* definitions could be used there.
>
> 2017-05-22  Max Filippov  
> gcc/
> * config/xtensa/xtensa.c (xtensa_option_override): Append
> MASK_CONST16 to target_flags in the absence of TARGET_L32R.
> (hwloop_optimize, hwloop_fail, hwloop_pattern_reg,
>  xtensa_doloop_hooks): Define unconditionally.
> (xtensa_reorg_loops): Only call reorg_loops in the presence of
> TARGET_LOOPS.
> * config/xtensa/xtensa.h (TARGET_L32R): New definition.
> (TARGET_DEFAULT): Remove XCHAL_HAVE_L32R condition and account
> for it in xtensa_option_override.
> (HARD_FRAME_POINTER_IS_FRAME_POINTER,
>  HARD_FRAME_POINTER_IS_ARG_POINTER): New definitions.

This is OK. Please apply.

Re: [RFC 1/5] gcc: xtensa: allow XCHAL_* macros to be non-constant

[augustine.sterl...@gmail.com]

On Mon, May 22, 2017 at 2:09 PM, Max Filippov  wrote:
> XCHAL_* macros from the xtensa-config.h are used in a number of places
> that require them to be preprocessor constants. Rewrite these places so
> that non-constant XCHAL_* definitions could be used there.

This whole series of patches is going to take quite a bit of time to
sort through, so sit tight if you would.

Re: [PATCH] xtensa: add support for SSP

[augustine.sterl...@gmail.com]

On Mon, May 8, 2017 at 3:55 PM, Max Filippov  wrote:
> gcc/
> 2017-03-27  Max Filippov  
>
> * config/xtensa/xtensa-protos.h
> (xtensa_initial_elimination_offset): New declaration.
> * config/xtensa/xtensa.c (xtensa_initial_elimination_offset):
> New function. Move its body from the INITIAL_ELIMINATION_OFFSET
> macro definition, add case for FRAME_POINTER_REGNUM when
> FRAME_GROWS_DOWNWARD.
> * config/xtensa/xtensa.h (FRAME_GROWS_DOWNWARD): New macro
> definition.
> (INITIAL_ELIMINATION_OFFSET): Replace body with call to
> xtensa_initial_elimination_offset.

Approved.

Re: [PATCH] xtensa: Fix PR target/78603

[augustine.sterl...@gmail.com]

On Tue, Nov 29, 2016 at 2:08 PM, Max Filippov  wrote:
> 2016-11-29  Max Filippov  
> gcc/
> * config/xtensa/xtensa.c (hwloop_optimize): Don't emit zero
> overhead loop start between a call and its CALL_ARG_LOCATION
> note.

Approved. Please apply.

Re: [PATCH] xtensa: fix ICE on pr59037.c test

[augustine.sterl...@gmail.com]

On Tue, Nov 1, 2016 at 12:11 PM, Max Filippov  wrote:
> xtensa gcc gets ICE on pr59037.c test because its xtensa_output_literal
> function cannot handle integer literals of sizes other than 4 and 8,
> whereas the test uses 16-byte int vector.
> Split integer literal formatting into the recursive function
> xtensa_output_integer_literal_parts capable of handling literals of any
> power of 2 size not less than 4.
>
> 2016-11-01  Max Filippov  
> gcc/
> * config/xtensa/xtensa.c (xtensa_output_integer_literal_parts):
> New function.
> (xtensa_output_literal): Use xtensa_output_integer_literal_parts
> to format MODE_INT and MODE_PARTIAL_INT literals.

Approved.

Re: [PATCH] xtensa: don't xfail gcc.c-torture/compile/20001226-1.c

[augustine.sterl...@gmail.com]

On Tue, Nov 1, 2016 at 12:45 PM, Max Filippov  wrote:
> With jump trampolines implemented in binutils since 2.25 and enabled by
> default this test no longer fails on xtensa.
>
> 2016-11-01  Max Filippov  
> gcc/testsuite/
> * gcc.c-torture/compile/20001226-1.c: Don't xfail on xtensa.

Approved.

Re: [PATCH] xtensa: Fix PR target/78118

[augustine.sterl...@gmail.com]

On Mon, Oct 31, 2016 at 11:32 PM, Max Filippov  wrote:
> 2016-10-26  Max Filippov  
> gcc/
> * config/xtensa/xtensa-protos.h
> (xtensa_use_return_instruction_p): New prototype.
> * config/xtensa/xtensa.c (xtensa_current_frame_size,
> xtensa_callee_save_size): Remove.
> (struct machine_function): Add new fields: current_frame_size,
> callee_save_size, frame_laid_out and epilogue_done.
> (compute_frame_size, xtensa_expand_prologue,
> xtensa_expand_epilogue): Replace xtensa_callee_save_size with
> cfun->machine->callee_save_size and xtensa_current_frame_size
> with cfun->machine->current_frame_size.
> (compute_frame_size): Update cfun->machine->frame_laid_out and
> don't update frame layout after reload completion.
> (xtensa_expand_epilogue): Set cfun->machine->epilogue_done
> instead of zeroing xtensa_current_frame_size.
> (xtensa_use_return_instruction_p): New function.
> * config/xtensa/xtensa.h (xtensa_current_frame_size): Remove
> declaration.
> (INITIAL_ELIMINATION_OFFSET): Use return value of
> compute_frame_size instead of xtensa_current_frame_size value.
> * config/xtensa/xtensa.md ("return" pattern): Use new predicate
> function xtensa_use_return_instruction_p instead of inline code.

Approved. Please apply.

Re: [PATCH] xtensa: don't use unwind-dw2-fde-dip with elf targets

[augustine.sterl...@gmail.com]

On Mon, Oct 17, 2016 at 4:23 PM, Max Filippov  wrote:
> Define LIB2ADDEH_XTENSA_UNWIND_DW2_FDE to unwind-dw2-fde.c in
> xtensa/t-elf and to unwind-dw2-fde-dip.c in xtensa/t-linux and use
> LIB2ADDEH_XTENSA_UNWIND_DW2_FDE in LIB2ADDEH definition.
>
> 2016-10-17  Max Filippov  
> libgcc/
> * config/xtensa/t-elf (LIB2ADDEH_XTENSA_UNWIND_DW2_FDE): New
> definition.
> * config/xtensa/t-linux (LIB2ADDEH_XTENSA_UNWIND_DW2_FDE): New
> definition.
> * config/xtensa/t-windowed (LIB2ADDEH): Use
> LIB2ADDEH_XTENSA_UNWIND_DW2_FDE defined by either xtensa/t-elf
> or xtensa/t-linux.
>
> Signed-off-by: Max Filippov 

Approved, please apply.

Re: [PATCH] xtensa: add HW FPU sequences for DIV/SQRT/RECIP/RSQRT

[augustine.sterl...@gmail.com]

On Fri, Oct 14, 2016 at 12:14 PM, Max Filippov  wrote:
>
> Use new FPU instruction sequences documented in the ISA book to
> implement __divsf3, __divdf3, __recipsf2, __recipdf2, __rsqrtsf2,
> __rsqrtdf2 and __ieee754_sqrtf and __ieee754_sqrt.
>
> 2013-02-12  Ding-Kai Chen  
> libgcc/
> * config/xtensa/ieee754-df.S (__recipdf2, __rsqrtdf2,
> __ieee754_sqrt): New functions.
> (__divdf3): Add implementation with new FPU instructions under
> #if XCHAL_HAVE_DFP_DIV.
> * config/xtensa/ieee754-sf.S (__recipsf2, __rsqrtsf2,
> __ieee754_sqrtf): New functions.
> (__divsf3): Add implementation with new FPU instructions under
> #if XCHAL_HAVE_FP_DIV.
> * config/xtensa/t-xtensa (LIB1ASMFUNCS): Add _sqrtf, _recipsf2
> _rsqrtsf2, _sqrt, _recipdf2 and _rsqrtdf2


Approved, please apply.

Re: [PATCH] xtensa: report stack usage

[augustine.sterl...@gmail.com]

On Fri, Aug 26, 2016 at 12:02 AM, Max Filippov  wrote:
> This enables options -fstack-usage and -Wstack-usage.
>
> 2016-08-21  Max Filippov  
> gcc/
> * config/xtensa/xtensa.c (xtensa_expand_prologue): Update
> current_function_static_stack_size variable with the static
> stack frame size of the current function when
> flag_stack_usage_info is enabled.
> ---

This is OK for xtensa. Please check in.

Re: [PATCH] xtensa: fix libgcc build with --text-section-literals

[augustine.sterl...@gmail.com]

On Tue, Feb 16, 2016 at 4:35 PM, Max Filippov  wrote:
> Functions __muldf3_aux, __divdf3_aux, __mulsf3_aux and __divsf3_aux
> don't start with leaf_entry, so they need explicit .literal_position,
> otherwise libgcc build fails in the presence of --text-section-literals.
>
> 2016-02-17  Max Filippov  
> libgcc/
> * config/xtensa/ieee754-df.S (__muldf3_aux, __divdf3_aux): Add
> .literal_position before the function.
> * config/xtensa/ieee754-sf.S (__mulsf3_aux, __divsf3_aux):
> Likewise.

This is OK, please submit.

Re: [PATCH] xtensa: add uclinux support

[augustine.sterl...@gmail.com]

On Wed, Sep 30, 2015 at 8:23 AM, Max Filippov  wrote:
> 2015-09-30  Max Filippov  
> gcc/
> * config.gcc (xtensa*-*-uclinux*): New configuration.
> * config/xtensa/uclinux.h: New file.
> * config/xtensa/uclinux.opt: New file.
>
> libgcc/
> * config.host (xtensa*-*-uclinux*): New configuration.

Approved, please apply.

Re: [PATCH 1/2] xtensa: fix TLS calls for call0 ABI

[augustine.sterl...@gmail.com]

On Tue, Sep 15, 2015 at 3:00 AM, Max Filippov  wrote:
> 2015-09-15  Max Filippov  
> gcc/
> * config/xtensa/xtensa.c (xtensa_call_tls_desc): Use a10 or a2
> to pass TLS call argument, according to current ABI.
> * config/xtensa/xtensa.md (tls_call pattern): Use callx8 or

Approved, please apply.

Re: [PATCH 2/2] xtensa: fix xtensa_fallback_frame_state for call0 ABI

[augustine.sterl...@gmail.com]

On Tue, Sep 15, 2015 at 3:00 AM, Max Filippov  wrote:
> 2015-09-15  Max Filippov  
> gcc/
> * config/xtensa/xtensa.h (DWARF_ALT_FRAME_RETURN_COLUMN): New
> definition.
> (DWARF_FRAME_REGISTERS): Reserve space for one extra register in
> call0 ABI.
>
> libgcc/
> * config/xtensa/linux-unwind.h (xtensa_fallback_frame_state):
> Add support for call0 ABI.

Approved. Please apply.

Re: [PATCH 2/3] xtensa: use unwind-dw2-fde-dip instead of unwind-dw2-fde

[augustine.sterl...@gmail.com]

On Mon, Aug 17, 2015 at 2:59 PM, Max Filippov jcmvb...@gmail.com wrote:
 This allows having exception cleanup code in binaries that don't
 register their unwind tables.

 2015-08-18  Max Filippov  jcmvb...@gmail.com
 libgcc/
 * config/xtensa/t-windowed (LIB2ADDEH): Replace unwind-dw2-fde
 with unwind-dw2-fde-dip.

Approved.

Re: [PATCH 1/3] xtensa: reimplement register spilling

[augustine.sterl...@gmail.com]

On Mon, Aug 17, 2015 at 2:59 PM, Max Filippov jcmvb...@gmail.com wrote:
 2015-08-18  Max Filippov  jcmvb...@gmail.com
 libgcc/
 * config/xtensa/lib2funcs.S (__xtensa_libgcc_window_spill): Use
 CALL12 followed by series of ENTRY to spill windowed registers.
 (__xtensa_nonlocal_goto): Call __xtensa_libgcc_window_spill
 instead of making linux spill syscall.

Approved.

Re: [PATCH 3/3] xtensa: fix _Unwind_GetCFA

[augustine.sterl...@gmail.com]

On Mon, Aug 17, 2015 at 2:59 PM, Max Filippov jcmvb...@gmail.com wrote:
 2015-08-18  Max Filippov  jcmvb...@gmail.com
 libgcc/
 * config/xtensa/unwind-dw2-xtensa.c (_Unwind_GetCFA): Return
 context-sp instead of context-cfa.

Approved.

Re: [PATCH] xtensa: add -mauto-litpools option

[augustine.sterl...@gmail.com]

On Tue, Aug 11, 2015 at 6:09 PM, Max Filippov jcmvb...@gmail.com wrote:
 With support from assembler this option allows compiling huge functions,
 where single literal pool at the beginning of a function may not be
 reachable by L32R instructions at its end.

 Currently assembler --auto-litpools option cannot deal with literals
 used from multiple locations separated by more than 256 KBytes of code.
 Don't turn constants into literals, instead use MOVI instruction to load
 them into registers and let the assembler turn them into literals as
 necessary.

 2015-08-11  Max Filippov  jcmvb...@gmail.com
 gcc/
 * config/xtensa/constraints.md (define_constraint Y): New
 constraint.
 * config/xtensa/elf.h (ASM_SPEC): Add m(no-)auto-litpools.
 * config/xtensa/linux.h (ASM_SPEC): Likewise.
 * config/xtensa/predicates.md (move_operand): Match constants
 and symbols in the presence of TARGET_AUTO_LITPOOLS.
 * config/xtensa/xtensa.c (xtensa_valid_move): Don't allow
 immediate references to TLS data.
 (xtensa_emit_move_sequence): Don't force constants to memory in
 the presence of TARGET_AUTO_LITPOOLS.
 (print_operand): Add 'y' format, same as default, but capable of
 printing SF mode constants as well.
 * config/xtensa/xtensa.md (movsi_internal, movhi_internal)
 (movsf_internal): Add movi pattern that loads literal.
 (movsf, movdf): Don't force constants to memory in the presence
 of TARGET_AUTO_LITPOOLS.
 (movdf_internal): Add 'Y' constraint.
 * config/xtensa/xtensa.opt (mauto-litpools): New option.
 * doc/invoke.text (Xtensa options): Document -mauto-litpools.

If this is OK with the linux people, it is OK with me. As I recall,
they used to have a need to keep literals in page-level groups, but my
memory is hazy.

Re: [PATCH v2] xtensa: implement trap pattern

[augustine.sterl...@gmail.com]

On Tue, Jun 9, 2015 at 3:14 PM, Max Filippov jcmvb...@gmail.com wrote:
 gcc/
 * config/xtensa/xtensa.h (TARGET_DEBUG): New definition.
 * config/xtensa/xtensa.md (define_attr type): New type trap.
 (define_insn trap): New definition.
 ---
 Changes v1-v2:
 - drop break.n, replace break 0, 0 with break 1, 15, coded breakpoint
   that transfers control to debugger if present.

This is OK for xtensa. Please apply.

Re: [PATCH] Fix PR target/65730

[augustine.sterl...@gmail.com]

On Tue, May 19, 2015 at 8:31 PM, Max Filippov jcmvb...@gmail.com wrote:
 2015-05-20  Max Filippov  jcmvb...@gmail.com
 gcc/
 * config/xtensa/xtensa.c (init_alignment_context): Replace MULT
 by BITS_PER_UNIT with ASHIFT by exact_log2 (BITS_PER_UNIT).

Approved, please apply.

Re: [RFC 2/2] Implement call0 ABI for xtensa

[augustine.sterl...@gmail.com]

On Sat, Feb 28, 2015 at 10:14 AM, Max Filippov jcmvb...@gmail.com wrote:
 call0 is an ABI that doesn't use register windows.

 2015-02-28  Max Filippov  jcmvb...@gmail.com

 gcc/
 * config/xtensa/constraints.md (a constraint): Include stack
 pointer in case of call0 ABI.
 (q constraint): Make empty in case of call0 ABI.
 (D constraint): Include stack pointer in case of call0 ABI.

 * config/xtensa/xtensa-protos.h (xtensa_set_return_address,
 xtensa_expand_epilogue, xtensa_regno_to_class): Add new function
 prototypes.

 * config/xtensa/xtensa.c (xtensa_callee_save_size): New
 variable.
 (xtensa_regno_to_class): Make it a local variable in the
 function xtensa_regno_to_class.
 (xtensa_function_epilogue, TARGET_ASM_FUNCTION_EPILOGUE): Remove
 macro, function prototype and implementation.
 (reg_nonleaf_alloc_order): Make it a local variable in the
 function order_regs_for_local_alloc.
 (xtensa_conditional_register_usage): New function.
 (TARGET_CONDITIONAL_REGISTER_USAGE): Define macro.
 (xtensa_valid_move): Allow direct moves to stack pointer
 register in call0 ABI.
 (xtensa_setup_frame_addresses): Only spill register windows in
 windowed ABI.
 (xtensa_emit_call): Emit call(x)8 or call(x)0 in windowed and
 call0 ABI respectively.
 (xtensa_function_arg_1): Only mark a7 register for copying in
 windowed ABI.
 (xtensa_call_save_reg): New function.
 (compute_frame_size): Add space for callee saved register
 storage to the frame size in call0 ABI.
 (xtensa_expand_prologue): Generate code to set up stack frame
 and save callee-saved registers in call0 ABI.
 (xtensa_expand_epilogue): New function.
 (xtensa_set_return_address): New function.
 (xtensa_return_addr): Calculate return address in call0 ABI.
 (xtensa_builtin_saveregs): Only mark a7 register for copying and
 emit copying code in windowed ABI.
 (order_regs_for_local_alloc): Add preferred register allocation
 order for non-leaf function in call0 ABI.
 (xtensa_static_chain): Add atatic chain passing for call0 ABI.
 (xtensa_asm_trampoline_template): Add trampoline generation for
 call0 ABI.
 (xtensa_trampoline_init): Add trampoline initialization for
 call0 ABI.
 (xtensa_conditional_register_usage, xtensa_regno_to_class): New
 functions.

 * config/xtensa/xtensa.h (TARGET_WINDOWED_ABI): New macro.
 (TARGET_CPU_CPP_BUILTINS): Add built-in define for call0 ABI.
 (CALL_USED_REGISTERS): Modify to encode both windowed and call0
 ABI call-used registers.
 (HARD_FRAME_POINTER_REGNUM): Add frame pointer for call0 ABI.
 (INCOMING_REGNO, OUTGOING_REGNO): Use argument unchanged in
 call0 ABI.
 (REG_CLASS_CONTENTS): Include all registers into the preferred
 reload registers set, adjust the set in the
 xtensa_conditional_register_usage.
 (xtensa_regno_to_class): Drop variable declaration.
 (REGNO_REG_CLASS): Redefine to use xtensa_regno_to_class
 function.
 (WINDOW_SIZE): Define as 8 or 0 for windowed and call0 ABI
 respectively.
 (FUNCTION_PROFILER): Add _mcount call for call0 ABI.
 (TRAMPOLINE_SIZE): Define trampoline size for call0 ABI.
 (RETURN_ADDR_IN_PREVIOUS_FRAME): Define to 0 in call0 ABI.
 (ASM_OUTPUT_POOL_PROLOGUE): Always generate literal pool
 location in call0 ABI.
 (EH_RETURN_STACKADJ_RTX): New definition, use a10 for passing
 stack adjustment size when handling exception.
 (CRT_CALL_STATIC_FUNCTION): Add definition for call0 ABI.

 * config/xtensa/xtensa.md (A9_REG, UNSPECV_BLOCKAGE): New
 definitions.
 (return pattern): Generate ret.n/ret in call0 ABI.
 (epilogue pattern): Expand epilogue.
 (nonlocal_goto pattern): Use default in call0 ABI.
 (eh_return pattern): Move implementation to eh_set_a0_windowed,
 emit eh_set_a0_* depending on ABI.
 (eh_set_a0_windowed pattern): Former eh_return pattern.
 (eh_set_a0_call0, blockage): New patterns.

 libgcc/
 * config/xtensa/lib2funcs.S (__xtensa_libgcc_window_spill,
 __xtensa_nonlocal_goto): Don't compile for call0 ABI.
 (__xtensa_sync_caches): Only use entry and retw in windowed ABI,
 use ret in call0 ABI.

 * config/xtensa/t-windowed: New file.

 * libgcc/config/xtensa/t-xtensa (LIB2ADDEH): Move to t-windowed.

 * libgcc/configure: Regenerated.

 * libgcc/configure.ac: Check if xtensa target is configured for
 windowed ABI and thus needs to use custom unwind code.


This is OK for xtensa.

Re: [RFC 1/2] Turn RETURN_ADDR_IN_PREVIOUS_FRAME into C expression

[augustine.sterl...@gmail.com]

On Sat, Feb 28, 2015 at 10:14 AM, Max Filippov jcmvb...@gmail.com wrote:
 This allows a target to support both windowed and non-windowed ABI.

 2015-02-28  Max Filippov  jcmvb...@gmail.com

 gcc/
 * builtins.c (expand_builtin_return_addr): Add
 RETURN_ADDR_IN_PREVIOUS_FRAME to 'if' condition.
 * config/sparc/sparc.h (RETURN_ADDR_IN_PREVIOUS_FRAME): Change
 definition to 1.
 * config/xtensa/xtensa.h (RETURN_ADDR_IN_PREVIOUS_FRAME):
 Likewise.

Unfortunately, I can't approve a change to spark.h, even though this
seems quite innocuous to me. I'm not sure why it is even relevant to
xtensa.

Without that, approved.

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

[augustine.sterl...@gmail.com]

On Wed, Feb 25, 2015 at 6:39 AM, Jeff Law l...@redhat.com wrote:

 Done.
 jeff

Thanks!

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

[augustine.sterl...@gmail.com]

On Tue, Feb 24, 2015 at 9:05 AM, Chen Gang S gang.c...@sunrus.com.cn wrote:

  - After this patch, it can continue compiling, but can we be sure that
it always generates correct code for execution?

After this patch, it should be no worse than it was--lucky.

Someone is working on fixing the underlying xtensa pattern in the
short term. So I would continue whether or not the generated code is
correct.

Another short-term option would be to use an xtensa config that
doesn't have zero-over-head loops.

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

[augustine.sterl...@gmail.com]

On Tue, Feb 24, 2015 at 2:05 PM, Max Filippov jcmvb...@gmail.com wrote:
 Hi,

 On Tue, Feb 24, 2015 at 6:54 PM, Jeff Law l...@redhat.com wrote:

 You can tackle them in any order you wish.  However, I suspect fixing the
 xtensa backend may be easier.  I don't have any good way to test xtensa, but
 something like the attached patch for the xtensa port should be sufficient.

 I can confirm that this patch fixes the issue. I haven't got a segfault
 as was reported in bugzilla, but I got some 'conditional jump or move
 depends on uninitialised value' under valgrind, originated from
 find_reloads, that the patch fixed. And with it the testcase from
 bugzilla actually produces code with loop instruction.

Max, the patch doesn't fix the underlying issue, it just hides the bad
memory reference by initializing what we were already accessing.

See Jeff Law's message earlier in the thread.

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

[augustine.sterl...@gmail.com]

On Tue, Feb 24, 2015 at 4:45 PM, Max Filippov jcmvb...@gmail.com wrote:

 Sterling,

 I was referring Jeff's patch, do you say that his patch is not the proper
 fix?

No, I was thinking of Chen's patch. Jeff's patch is the right one.

Jeff, your patch is OK for xtensa. Do you mind checking it in?

Re: [PATCH] xtensa: align data naturally when optimizing for size

[augustine.sterl...@gmail.com]

On Sat, Feb 21, 2015 at 4:19 PM, Max Filippov jcmvb...@gmail.com wrote:
 gcc for xtensa always aligns data at least to a word boundary, even when
 it has smaller natural alignment. This results in unexpectedly high data
 section sizes and unreasonable amount of wasted space when linking
 objects compiled with -fdata-sections flag.

 Align data naturally when optimization for size is enabled.

 2015-02-22  Max Filippov  jcmvb...@gmail.com

 gcc/
 * config/xtensa/xtensa.h (CONSTANT_ALIGNMENT, DATA_ALIGNMENT):
 use natural alignment when optimizing for size.

This is OK for xtensa.

Re: [PATCH] Fix loop optimization when ZOL is not available in xtensa configuration

[augustine.sterl...@gmail.com]

On Mon, Dec 29, 2014 at 3:12 PM, Max Filippov jcmvb...@gmail.com wrote:
 Currently building gcc for xtensa configuration with XCHAL_HAVE_LOOPS
 set to 0 fails with the following error:

   xtensa.c:3952: undefined reference to `reorg_loops(bool, hw_doloop_hooks*)'

 Only compile target-specific zero-overhead loop optimization code when
 TARGET_LOOPS allows it.

 2014-12-30  Max Filippov  jcmvb...@gmail.com

 * config/xtensa/xtensa.c (hwloop_optimize, hwloop_fail,
 hwloop_pattern_reg, xtensa_doloop_hooks, xtensa_reorg_loops):
 put under #if TARGET_LOOPS guard.

This is OK. Thanks.

Re: [PATCH] Add zero-overhead looping for xtensa backend

[augustine.sterl...@gmail.com]

On Tue, Oct 28, 2014 at 5:22 AM, Yangfei (Felix) felix.y...@huawei.com wrote:
 Hi Sterling,
   How do you think about this issue?
   As c6x/bfin port handles this the same way, is it OK for the patch to be 
 applied?
   Thanks.

I have committed this patch as attached. I made a couple of minor
cleanups, plus some small fixes to the ChangeLog entry.

The new code generated is better than the old code, but I'm not
particularly happy with the result. In particular, it is way too
conservative around spilling the trip count, and it still maintains
the trip count inside the loop, in spite of the trip count being dead
at that point. It won't always be dead, but when it is, it should be
eliminated.

So there is quite a bit of performance that could still be gained here.

Thanks for the patch Felix.

Sterling

2014-10-10  Felix Yang  felix.y...@huawei.com

* config/xtensa/xtensa.h (TARGET_LOOPS): New Macro.
* config/xtensa/xtensa.c: Include dumpfile.h and hw-doloop.h.
(xtensa_reorg, xtensa_reorg_loops): New.
(xtensa_can_use_doloop_p, xtensa_invalid_within_doloop): New.
(hwloop_optimize, hwloop_fail, hwloop_pattern_reg): New.
(xtensa_emit_loop_end): Emit the zero-overhead loop end label.
(xtensa_doloop_hooks): Define.
* config/xtensa/xtensa.md (doloop_end, loop_end): New
(zero_cost_loop_start): Rewritten.
(zero_cost_loop_end): Likewise.
Index: gcc/config/xtensa/xtensa.c
===
--- gcc/config/xtensa/xtensa.c  (revision 216943)
+++ gcc/config/xtensa/xtensa.c  (working copy)
@@ -74,6 +74,8 @@
 #include gimplify.h
 #include df.h
 #include builtins.h
+#include dumpfile.h
+#include hw-doloop.h
 #include rtl-iter.h
 
 
@@ -200,6 +202,10 @@
 
 static bool constantpool_address_p (const_rtx addr);
 static bool xtensa_legitimate_constant_p (machine_mode, rtx);
+static void xtensa_reorg (void);
+static bool xtensa_can_use_doloop_p (const widest_int , const widest_int ,
+ unsigned int, bool);
+static const char *xtensa_invalid_within_doloop (const rtx_insn *);
 
 static bool xtensa_member_type_forces_blk (const_tree,
   machine_mode mode);
@@ -326,6 +332,15 @@
 #undef TARGET_LEGITIMATE_CONSTANT_P
 #define TARGET_LEGITIMATE_CONSTANT_P xtensa_legitimate_constant_p
 
+#undef TARGET_MACHINE_DEPENDENT_REORG
+#define TARGET_MACHINE_DEPENDENT_REORG xtensa_reorg
+
+#undef TARGET_CAN_USE_DOLOOP_P
+#define TARGET_CAN_USE_DOLOOP_P xtensa_can_use_doloop_p
+
+#undef TARGET_INVALID_WITHIN_DOLOOP
+#define TARGET_INVALID_WITHIN_DOLOOP xtensa_invalid_within_doloop
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 
@@ -1690,7 +1705,7 @@
 }
 }
 
-  output_asm_insn (# loop end for %0, operands);
+  output_asm_insn (%1_LEND:, operands);
 }
 
 
@@ -3720,4 +3735,236 @@
   return !xtensa_tls_referenced_p (x);
 }
 
+/* Implement TARGET_CAN_USE_DOLOOP_P.  */
+
+static bool
+xtensa_can_use_doloop_p (const widest_int , const widest_int ,
+ unsigned int loop_depth, bool entered_at_top)
+{
+  /* Considering limitations in the hardware, only use doloop
+ for innermost loops which must be entered from the top.  */
+  if (loop_depth  1 || !entered_at_top)
+return false;
+
+  return true;
+}
+
+/* NULL if INSN insn is valid within a low-overhead loop.
+   Otherwise return why doloop cannot be applied.  */
+
+static const char *
+xtensa_invalid_within_doloop (const rtx_insn *insn)
+{
+  if (CALL_P (insn))
+return Function call in the loop.;
+
+  if (JUMP_P (insn)  INSN_CODE (insn) == CODE_FOR_return)
+return Return from a call instruction in the loop.;
+
+  return NULL;
+}
+
+/* Optimize LOOP.  */
+
+static bool
+hwloop_optimize (hwloop_info loop)
+{
+  int i;
+  edge entry_edge;
+  basic_block entry_bb;
+  rtx iter_reg;
+  rtx_insn *insn, *seq, *entry_after;
+
+  if (loop-depth  1)
+{
+  if (dump_file)
+fprintf (dump_file, ;; loop %d is not innermost\n,
+ loop-loop_no);
+  return false;
+}
+
+  if (!loop-incoming_dest)
+{
+  if (dump_file)
+fprintf (dump_file, ;; loop %d has more than one entry\n,
+ loop-loop_no);
+  return false;
+}
+
+  if (loop-incoming_dest != loop-head)
+{
+  if (dump_file)
+fprintf (dump_file, ;; loop %d is not entered from head\n,
+ loop-loop_no);
+  return false;
+}
+
+  if (loop-has_call || loop-has_asm)
+{
+  if (dump_file)
+fprintf (dump_file, ;; loop %d has invalid insn\n,
+ loop-loop_no);
+  return false;
+}
+
+  /* Scan all the blocks to make sure they don't use iter_reg.  */
+  if (loop-iter_reg_used || loop-iter_reg_used_outside)
+{
+  if (dump_file)
+fprintf (dump_file, ;; loop %d uses iterator\n,
+ loop-loop_no);
+  return false;
+}
+
+  /* Check if start_label appears before doloop_end.  */
+  insn = 

Re: [xtensa] RFA: Use new rtl iterators in xtensa_tls_referenced_p

[augustine.sterl...@gmail.com]

On Sat, Oct 25, 2014 at 2:17 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
 This is part of a series to remove uses of for_each_rtx from the ports.

 Tested by making sure there were no code changes for gcc.dg, gcc.c-torture
 and g++.dg for xtensa-elf.  OK to install?

OK for Xtensa

Re: [PATCH] Add zero-overhead looping for xtensa backend

[augustine.sterl...@gmail.com]

On Thu, Oct 23, 2014 at 9:12 PM, Yangfei (Felix) felix.y...@huawei.com wrote:
 Here the key point is we need a general purpose register for the loop
 instruction.

So the question to ask here is, How does this work today, without
loop instructions? Somehow--even when it has been spilled--a branch
instruction can test the trip count. There should be no difference.

 And we cannot use zero-cost looping in this situation.
 And that's why I spilt the zero_cost_loop_end into a normal test and branch.

 Also note that the hwloop_pattern_reg interface also expects a general 
 purpose register in the doloop_end pattern.

If there were no loop instruction, how would this work?

Re: [PATCH] Add zero-overhead looping for xtensa backend

[augustine.sterl...@gmail.com]

I mean without your patch at all.

On Thu, Oct 23, 2014 at 11:30 PM, Yangfei (Felix) felix.y...@huawei.com wrote:

 On Thu, Oct 23, 2014 at 9:12 PM, Yangfei (Felix) felix.y...@huawei.com 
 wrote:
  Here the key point is we need a general purpose register for the loop
  instruction.

 So the question to ask here is, How does this work today, without loop
 instructions? Somehow--even when it has been spilled--a branch instruction 
 can
 test the trip count. There should be no difference.

  And we cannot use zero-cost looping in this situation.
  And that's why I spilt the zero_cost_loop_end into a normal test and 
  branch.

  Also note that the hwloop_pattern_reg interface also expects a general
 purpose register in the doloop_end pattern.

 If there were no loop instruction, how would this work?


 Just take a look at my patch. I handle this in the new define_split:

 +(define_split
 +  [(set (pc)
 +(if_then_else (ne (match_operand:SI 0 nonimmediate_operand )
 +  (const_int 1))
 +  (label_ref (match_operand 1  ))
 +  (pc)))
 +   (set (match_operand:SI 2 nonimmediate_operand )
 +(plus:SI (match_dup 0)
 + (const_int -1)))
 +   (unspec [(const_int 0)] UNSPEC_LSETUP_END)
 +   (clobber (match_scratch 3))]
 +  TARGET_LOOPS  optimize  reload_completed
 +  [(const_int 0)]
 +{
 +  if (!REG_P (operands[0]))
 +{
 +  rtx test;
 +
 +  /* Fallback into a normal conditional branch insn.  */
 +  emit_move_insn (operands[3], operands[0]);
 +  emit_insn (gen_addsi3 (operands[3], operands[3], constm1_rtx));
 +  emit_move_insn (operands[0], operands[3]);
 +  test = gen_rtx_NE (VOIDmode, operands[3], const0_rtx);
 +  emit_jump_insn (gen_cbranchsi4 (test, operands[3],
 +  const0_rtx, operands[1]));
 +}
 +  else
 +{
 +  emit_jump_insn (gen_loop_end (operands[0], operands[1], operands[2]));
 +}
 +
 +  DONE;
 +})

Re: [PATCH] Add zero-overhead looping for xtensa backend

[augustine.sterl...@gmail.com]

On Thu, Oct 23, 2014 at 11:40 PM, Yangfei (Felix) felix.y...@huawei.com wrote:
 1. The original xtensa port never generates loop instruction at all.
 2. A port doesn't need to implement hwloop_pattern_reg hook if it has no 
 zero-cost loop instruction.

 Is that clear?

We are talking in circles. I understand very well what goes on here.

My point is:

1. Right now, today, GCC generates loops with branch instructions even
when the trip count is spilled.
2. Branch instructions and loop instructions have identical register
requirements.

Therefore:

3. loop instructions should be generatable when the trip count is spilled.

Re: [PATCH] Add zero-overhead looping for xtensa backend

[augustine.sterl...@gmail.com]

On Tue, Oct 21, 2014 at 7:20 PM, Yangfei (Felix) felix.y...@huawei.com wrote:
 If the tripcount spill issue is not handled in the pattern, ICE may happen 
 then.
 Here reload is trying to spill pseudo 173, but a memory operand is not 
 allowed in zero_cost_loop_end pattern.
 And this is what I am trying to solve.

We have full control of the zero_cost_loop_end pattern. Plus, it
doesn't actually generate any real code. Edit it so it can take a
memory operand.

Re: [PATCH] Add zero-overhead looping for xtensa backend

[augustine.sterl...@gmail.com]

)
 (insn 39 38 40 3 (set (reg:SI 77 [ MEM[base: _14, offset: 0B] ])
 (mem:SI (reg:SI 72 [ ivtmp$8 ]) [2 MEM[base: _14, offset: 0B]+0 S4 
 A32])) arraysum.c:9 29 {movsi_internal}
  (nil))
 (insn 40 39 41 3 (set (reg/v:SI 74 [ Sum ])
 (plus:SI (reg/v:SI 74 [ Sum ])
 (reg:SI 77 [ MEM[base: _14, offset: 0B] ]))) arraysum.c:9 1 
 {addsi3}
  (expr_list:REG_DEAD (reg:SI 77 [ MEM[base: _14, offset: 0B] ])
 (nil)))
 (insn 41 40 53 3 (set (reg:SI 72 [ ivtmp$8 ])
 (plus:SI (reg:SI 72 [ ivtmp$8 ])
 (const_int 4 [0x4]))) 1 {addsi3}
  (nil))
 (jump_insn 53 41 52 3 (parallel [
 (set (pc)
 (if_then_else (ne (reg:SI 79)
 (const_int 1 [0x1]))
 (label_ref 52)
 (pc)))
 (set (reg:SI 79)
 (plus:SI (reg:SI 79)
 (const_int -1 [0x])))
 (unspec [
 (const_int 0 [0])
 ] 13)
 (clobber (scratch:SI))
 ]) -1
  (int_list:REG_BR_PROB 9899 (nil))
  - 52)
 (code_label 52 53 51 5 3  [1 uses])
 (note 51 52 44 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
 (note 44 51 45 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
 (insn 45 44 46 4 (set (reg/f:SI 78)
 (mem/u/c:SI (symbol_ref/u:SI (*.LC4) [flags 0x2]) [2  S4 A32])) 
 arraysum.c:11 29 {movsi_internal}
  (expr_list:REG_EQUAL (symbol_ref:SI (g_sum)  var_decl 0x7f6eef5d6360 
 g_sum)
 (nil)))
 (insn 46 45 0 4 (set (mem/c:SI (reg/f:SI 78) [2 g_sum+0 S4 A32])
 (reg/v:SI 74 [ Sum ])) arraysum.c:11 29 {movsi_internal}
  (expr_list:REG_DEAD (reg/f:SI 78)
 (expr_list:REG_DEAD (reg/v:SI 74 [ Sum ])
 (nil



 On Tue, Oct 14, 2014 at 8:39 AM, Felix Yang fei.yang0...@gmail.com wrote:
  PING？
  Cheers,
  Felix

 Felix,

 This isn't my day job, 24-hour pings are unproductive.

 You shouldn't need to worry about the trip count register getting spilled. It
 makes no difference whatsoever to how the loop operates--the trip count is
 dead with regards to the loop once the instruction executes. You don't need 
 to
 describe LCOUNT to gcc in order for this not to matter. It should be enough 
 to
 describe the zcl as consuming the value in the same way a branch instruction
 consumes a value.

 If you have a case where spilling it is causing a problem, then there is a 
 bug in
 your code, papered over by dropping case when it is spilled. Similarly with
 iter_reg_used_outside--it shouldn't affect whether or not a zcl is valid 
 here. If
 you have a case where it does, there is likely a bug in your code.

 If the code is easier to write by maintaining trip_count up, then fine (for 
 now);
 you give up some performance (in fact, a lot of performance), but that 
 doesn't
 matter as to the correctness.


 
 
  On Tue, Oct 14, 2014 at 12:30 AM, Felix Yang fei.yang0...@gmail.com
 wrote:
  Thanks for the comments.
 
  The patch checked the usage of teh trip count register, making sure
  that it is not used in the loop body other than the doloop_end or
  lives past the doloop_end instruction, as the following code snippet
  shows:
 
  +  /* Scan all the blocks to make sure they don't use iter_reg.  */
  + if (loop-iter_reg_used || loop-iter_reg_used_outside)
  +{
  +  if (dump_file)
  +fprintf (dump_file, ;; loop %d uses iterator\n,
  + loop-loop_no);
  +  return false;
  +}
 
  For the spill issue, I think we need to handle it. The reason is
  that currently we are not telling GCC about the existence of the
  LCOUNT register. Instead, we keep the trip count in a general
  register and it's possible that this register can be spilled when
  register pressure is high.
  It's a good idea to post another patch to describe the LCOUNT
  register in GCC in order to free this general register. But I want
  this patch applied as a first step, OK?
 
  Cheers,
  Felix
 
 
  On Tue, Oct 14, 2014 at 12:09 AM, augustine.sterl...@gmail.com
  augustine.sterl...@gmail.com wrote:
  On Fri, Oct 10, 2014 at 6:59 AM, Felix Yang fei.yang0...@gmail.com
 wrote:
  Hi Sterling,
 
  I made some improvement to the patch. Two changes:
  1. TARGET_LOOPS is now used as a condition of the doloop
  related patterns, which is more elegant.
 
  Fine.
 
  2. As the trip count register of the zero-cost loop maybe
  potentially spilled, we need to change the patterns in order to
  handle this issue.
 
  Actually, for xtensa you don't. The trip count is copied into LCOUNT
  at the execution of the loop instruction, and therefore a spill or
  whatever doesn't matter--it won't affect the result. So as long as
  you have the trip count at the start of the loop, you are fine.
 
  This does bring up an issue of whether or not the trip count can be
  modified during the loop. (note that this is different than early
  exit.) If it can, you can't use a zero-overhead loop. Does your
  patch address

Re: [PATCH] Add zero-overhead looping for xtensa backend

[augustine.sterl...@gmail.com]

On Tue, Oct 14, 2014 at 8:39 AM, Felix Yang fei.yang0...@gmail.com wrote:
 PING？
 Cheers,
 Felix

Felix,

This isn't my day job, 24-hour pings are unproductive.

You shouldn't need to worry about the trip count register getting
spilled. It makes no difference whatsoever to how the loop
operates--the trip count is dead with regards to the loop once the
instruction executes. You don't need to describe LCOUNT to gcc in
order for this not to matter. It should be enough to describe the zcl
as consuming the value in the same way a branch instruction consumes a
value.

If you have a case where spilling it is causing a problem, then there
is a bug in your code, papered over by dropping case when it is
spilled. Similarly with iter_reg_used_outside--it shouldn't affect
whether or not a zcl is valid here. If you have a case where it does,
there is likely a bug in your code.

If the code is easier to write by maintaining trip_count up, then fine
(for now); you give up some performance (in fact, a lot of
performance), but that doesn't matter as to the correctness.




 On Tue, Oct 14, 2014 at 12:30 AM, Felix Yang fei.yang0...@gmail.com wrote:
 Thanks for the comments.

 The patch checked the usage of teh trip count register, making sure
 that it is not used in the loop body other than the doloop_end or
 lives past the doloop_end instruction, as the following code snippet
 shows:

 +  /* Scan all the blocks to make sure they don't use iter_reg.  */
 +  if (loop-iter_reg_used || loop-iter_reg_used_outside)
 +{
 +  if (dump_file)
 +fprintf (dump_file, ;; loop %d uses iterator\n,
 + loop-loop_no);
 +  return false;
 +}

 For the spill issue, I think we need to handle it. The reason is
 that currently we are not telling GCC about the existence of the
 LCOUNT register. Instead, we keep the trip count in a general register
 and it's possible that this register can be spilled when register
 pressure is high.
 It's a good idea to post another patch to describe the LCOUNT
 register in GCC in order to free this general register. But I want
 this patch applied as a first step, OK?

 Cheers,
 Felix


 On Tue, Oct 14, 2014 at 12:09 AM, augustine.sterl...@gmail.com
 augustine.sterl...@gmail.com wrote:
 On Fri, Oct 10, 2014 at 6:59 AM, Felix Yang fei.yang0...@gmail.com wrote:
 Hi Sterling,

 I made some improvement to the patch. Two changes:
 1. TARGET_LOOPS is now used as a condition of the doloop related
 patterns, which is more elegant.

 Fine.

 2. As the trip count register of the zero-cost loop maybe
 potentially spilled, we need to change the patterns in order to handle
 this issue.

 Actually, for xtensa you don't. The trip count is copied into LCOUNT
 at the execution of the loop instruction, and therefore a spill or
 whatever doesn't matter--it won't affect the result. So as long as you
 have the trip count at the start of the loop, you are fine.

 This does bring up an issue of whether or not the trip count can be
 modified during the loop. (note that this is different than early
 exit.) If it can, you can't use a zero-overhead loop. Does your patch
 address this case.

 The solution is similar to that adapted by c6x backend.
 Just turn the zero-cost loop into a regular loop when that happens
 when reload is completed.
 Attached please find version 4 of the patch. Make check regression
 tested with xtensa-elf-gcc/simulator.
 OK for trunk?

Re: [PATCH 0/2] xtensa: fix floating-point parts of machine description

[augustine.sterl...@gmail.com]

On Sun, Oct 12, 2014 at 3:46 PM, Max Filippov jcmvb...@gmail.com wrote:
 Hi Sterling,

 this series fixes two bugs in xtensa.md:

HI Max, thanks for this. I don't see a patch though.

Re: [PATCH 2/2] xtensa: use pre- and postincrement FP load/store when available

[augustine.sterl...@gmail.com]

On Sun, Oct 12, 2014 at 3:46 PM, Max Filippov jcmvb...@gmail.com wrote:
 2014-10-10  Max Filippov  jcmvb...@gmail.com

 gcc/
 * config/xtensa/xtensa.h (TARGET_HARD_FLOAT_POSTINC): new macro.
 * config/xtensa/xtensa.md (*lsiu, *ssiu): add dependency on
 !TARGET_HARD_FLOAT_POSTINC.
 (*lsip, *ssip): new instructions.

Approved. Do you have write priviliges?

Re: [PATCH 1/2] xtensa: drop unimplemented floating point operations

[augustine.sterl...@gmail.com]

On Sun, Oct 12, 2014 at 3:46 PM, Max Filippov jcmvb...@gmail.com wrote:
 xtensa ISA never implemented FP division, reciprocal, square root and
 inverse square root as single opcode. Remove patterns that can emit
 them.

 2014-10-09  Max Filippov  jcmvb...@gmail.com

 gcc/
 * config/xtensa/xtensa.md (divsf3, *recipsf2, sqrtsf2, *rsqrtsf2):
 remove.

Approved.

Re: [PATCH] Add zero-overhead looping for xtensa backend

[augustine.sterl...@gmail.com]

On Fri, Oct 10, 2014 at 6:59 AM, Felix Yang fei.yang0...@gmail.com wrote:
 Hi Sterling,

 I made some improvement to the patch. Two changes:
 1. TARGET_LOOPS is now used as a condition of the doloop related
 patterns, which is more elegant.

Fine.

 2. As the trip count register of the zero-cost loop maybe
 potentially spilled, we need to change the patterns in order to handle
 this issue.

Actually, for xtensa you don't. The trip count is copied into LCOUNT
at the execution of the loop instruction, and therefore a spill or
whatever doesn't matter--it won't affect the result. So as long as you
have the trip count at the start of the loop, you are fine.

This does bring up an issue of whether or not the trip count can be
modified during the loop. (note that this is different than early
exit.) If it can, you can't use a zero-overhead loop. Does your patch
address this case.

The solution is similar to that adapted by c6x backend.
 Just turn the zero-cost loop into a regular loop when that happens
 when reload is completed.
 Attached please find version 4 of the patch. Make check regression
 tested with xtensa-elf-gcc/simulator.
 OK for trunk?

Re: [BUILDROBOT] xtensa fallout (was: Turn DECL_SECTION_NAME into string)

[augustine.sterl...@gmail.com]

On Fri, Jul 4, 2014 at 2:11 PM, Jan-Benedict Glaw jbg...@lug-owl.de wrote:
 On Wed, 2014-06-25 08:55:57 -0700, augustine.sterl...@gmail.com 
 augustine.sterl...@gmail.com wrote:
 On Tue, Jun 24, 2014 at 10:20 PM, Jan Hubicka hubi...@ucw.cz wrote:
   This is the xtensa fallout, see 
   http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=272418
  
   g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
   -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
   -Wwrite-strings -Wcast-qual -Wmissing-format-attribute 
   -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
   -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. 
   -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. 
   -I/home/jbglaw/repos/gcc/gcc/../include 
   -I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
   -I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
   -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
   -I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o insn-preds.o -MT 
   insn-preds.o -MMD -MP -MF ./.deps/insn-preds.TPo insn-preds.c
   /home/jbglaw/repos/gcc/gcc/config/xtensa/predicates.md: In function ‘int 
   call_insn_operand_1(rtx, machine_mode)’:
   /home/jbglaw/repos/gcc/gcc/config/xtensa/predicates.md:113:57: error: 
   cannot convert ‘const char*’ to ‘tree’ in assignment
   /home/jbglaw/repos/gcc/gcc/config/xtensa/predicates.md:119:46: error: 
   cannot convert ‘const char*’ to ‘tree’ in assignment
   make[1]: *** [insn-preds.o] Error 1
  Should be fixed by this (and I see in my prevoius mail I wanted 
  TREE_STRING_POINTER)

 [resend due to gmail's stupid html-by-default]

 This patch looks correct to me, but I haven't watched quite enough of
 the underlying change to know that replacing the strcmp with pointer
 equality is really the right thing.

 If it is, approved for Xtensa.

 *ping*

 As Jan wrote it, I *guess* it probably is (haven't checked.)

Approved.

Re: [BUILDROBOT] xtensa fallout (was: Turn DECL_SECTION_NAME into string)

[augustine.sterl...@gmail.com]

On Tue, Jun 24, 2014 at 10:20 PM, Jan Hubicka hubi...@ucw.cz wrote:
 Hi!

 This is the xtensa fallout, see 
 http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=272418

 g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
 -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
 -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual 
 -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
 -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc 
 -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include 
 -I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
 -I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
 -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
 -I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o insn-preds.o -MT 
 insn-preds.o -MMD -MP -MF ./.deps/insn-preds.TPo insn-preds.c
 /home/jbglaw/repos/gcc/gcc/config/xtensa/predicates.md: In function ‘int 
 call_insn_operand_1(rtx, machine_mode)’:
 /home/jbglaw/repos/gcc/gcc/config/xtensa/predicates.md:113:57: error: cannot 
 convert ‘const char*’ to ‘tree’ in assignment
 /home/jbglaw/repos/gcc/gcc/config/xtensa/predicates.md:119:46: error: cannot 
 convert ‘const char*’ to ‘tree’ in assignment
 make[1]: *** [insn-preds.o] Error 1
 Should be fixed by this (and I see in my prevoius mail I wanted 
 TREE_STRING_POINTER)

[resend due to gmail's stupid html-by-default]

This patch looks correct to me, but I haven't watched quite enough of
the underlying change to know that replacing the strcmp with pointer
equality is really the right thing.

If it is, approved for Xtensa.


 Index: gcc/config/xtensa/predicates.md
 ===
 --- gcc/config/xtensa/predicates.md (revision 211693)
 +++ gcc/config/xtensa/predicates.md (working copy)
 @@ -97,7 +97,8 @@
/* Direct calls only allowed to static functions with PIC.  */
if (flag_pic)
 {
 - tree callee, callee_sec, caller_sec;
 + tree callee;
 + const char * callee_sec, caller_sec;

   if (GET_CODE (op) != SYMBOL_REF
   || !SYMBOL_REF_LOCAL_P (op) || SYMBOL_REF_EXTERNAL_P (op))
 @@ -117,10 +118,9 @@
   if (DECL_ONE_ONLY (callee))
 return false;
   callee_sec = DECL_SECTION_NAME (callee);
 - if (((caller_sec == NULL_TREE) ^ (callee_sec == NULL_TREE))
 - || (caller_sec != NULL_TREE
 -  strcmp (TREE_STRING_POINTER (caller_sec),
 -TREE_STRING_POINTER (callee_sec)) != 0))
 + if (((caller_sec == NULL) ^ (callee_sec == NULL))
 + || (caller_sec != NULL
 +  caller_sec != callee_sec))
 return false;
 }
   else if (caller_sec != NULL_TREE)

 MfG, JBG

 --
   Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
 Signature of:   Ich hatte in letzter Zeit ein bißchen viel 
 Realitycheck.
 the second  :   Langsam möchte ich mal wieder weiterträumen 
 können.
  -- Maximilian Wilhelm (18. Mai 2005, 
 #lug-owl.de)