This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Invalid store semantics
- From: Ian Lance Taylor <iant at google dot com>
- To: Umesh Kalappa <umesh dot kalappa0 at gmail dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 30 Sep 2013 08:31:59 -0700
- Subject: Re: Invalid store semantics
- Authentication-results: sourceware.org; auth=none
- References: <CAGfacvS3BJekbjyr-b_2NBSdjbwK5BPK-3sHC_ZWZ4Oz+j8T6w at mail dot gmail dot com>
On Mon, Sep 30, 2013 at 7:46 AM, Umesh Kalappa <umesh.kalappa0@gmail.com> wrote:
>
> With the optimisation (-O3) enabled ,the above rtl has been transformed to
>
> (insn 7 6 8 2 (set (reg:SI 24)
> (unspec:SI [
> (mem/c/i:SI (symbol_ref:SI ("lsucCnt2.1746") [flags 0x2] ) [2
> lsucCnt2+0 S4 A16])
> ] 1)) algt_001.c:41 59 {tx03_movw}
> (nil))
>
> (insn 8 7 0 2 (set (mem:SI (reg:SI 24) [0 S4 A16])
> (const_int 10 [0xa])) algt_001.c:41 42 {storesi}
> (expr_list:REG_DEAD (reg:SI 24)
> (nil)))
>
>
> Where insn-6 has been deleted and constant 10 is propagated to insn 8
> an d finally ended emitting instruction like str 10 ,[mem] ,which is
> invalid syntax for store where constant is not allowed.
If your processor does not permit storing a constant to memory, then
the constraints on your storesi insn should reject a constant.
> I'm trying to handle the above problem ,by introducing scratch
> register in the store template and peephole/split it ,where force the
> constant to the scratch register. Before I do the same.
It may be necessary to do this in your movsi pattern, I don't know.
But your storesi pattern doesn't need to accept a constant, and the
constraints should reflect that.
Ian