Strange insn rtx is emitted in a custom backend

[Lev Yudalevich]

While working on a custom backend for quite a standard RISC-like
architecture, I defined 'high'/'lo_sum' patterns as follows:

(define_insn "mov_high"
  [(set (match_operand:SI 0 "register_operand" "=r")
  (high:SI (match_operand:SI 1 "immediate_operand" "i")))]
  ""
  "mvup #high(%1), %0"
  [(set_attr "insn" "alu")
   (set_attr "length" "4")]
)

(define_insn "add_low"
  [(set (match_operand:SI 0 "register_operand" "=r")
  (lo_sum:SI (match_operand:SI 1 "register_operand" "0")
   (match_operand:SI 2 "symbolic_operand" "")))]
   (match_operand:SI 2 "immediate_operand" "i")))]
  ""
  "add3 %0, #low(%2), %0"
  [(set_attr "insn" "alu")
   (set_attr "length" "4")]
)


Despite having the patters above (along with usual 'plus' patterns)
I'm getting the following rtx emitted at the expansion stage:

(insn 53 52 63 2 (set (reg:SI 62)
   (const:SI (plus:SI (symbol_ref:SI [flags 0x6])
  (const_int
64 [0x40] -1
(nil))

which can not be recognized unless I define a pattern like this:

(define_insn "*make_gcc_happy"
  [(set (match_operand:SI 0 "register_operand" "=r")
  (const:SI (plus:SI (match_operand:SI 1 "symbolic_operand" "")
 (match_operand:SI 2
"const_int_operand" ""]
  ""
  "mvup #high(%1), %0  \\n  add3 %0, #low(%1+%2), %0"
  [(set_attr "insn" "alu")
   (set_attr "length" "8")]
)


I don't understand why the rtx above is emitted as a whole single
instruction, without using the high/lo_sum patterns.
I'd very appreciate any help, hints or pointing me to a possibly
missing/erroneous spots.

Sincerely,
Lev.

Re: Strange insn rtx is emitted in a custom backend

[Lev Yudalevich]

Thanks a lot, Jeff!
I was missing some stuff in TARGET_LEGITIMATE_CONSTANT_P.

Lev.

On Mon, Jun 1, 2015 at 11:35 PM, Jeff Law  wrote:
> On 06/01/2015 12:51 PM, Lev Yudalevich wrote:
>>
>> While working on a custom backend for quite a standard RISC-like
>> architecture, I defined 'high'/'lo_sum' patterns as follows:
>>
>> (define_insn "mov_high"
>>[(set (match_operand:SI 0 "register_operand" "=r")
>>(high:SI (match_operand:SI 1 "immediate_operand" "i")))]
>>""
>>"mvup #high(%1), %0"
>>[(set_attr "insn" "alu")
>> (set_attr "length" "4")]
>> )
>>
>> (define_insn "add_low"
>>[(set (match_operand:SI 0 "register_operand" "=r")
>>(lo_sum:SI (match_operand:SI 1 "register_operand" "0")
>> (match_operand:SI 2 "symbolic_operand" "")))]
>> (match_operand:SI 2 "immediate_operand"
>> "i")))]
>>""
>>"add3 %0, #low(%2), %0"
>>[(set_attr "insn" "alu")
>> (set_attr "length" "4")]
>> )
>>
>>
>> Despite having the patters above (along with usual 'plus' patterns)
>> I'm getting the following rtx emitted at the expansion stage:
>>
>> (insn 53 52 63 2 (set (reg:SI 62)
>> (const:SI (plus:SI (symbol_ref:SI [flags
>> 0x6])
>>(const_int
>> 64 [0x40] -1
>>  (nil))
>>
>> which can not be recognized unless I define a pattern like this:
>
> You should debug precisely where that came from.  You're missing something
> in your backend to tell GCC that such constants are not valid.
>
> You should probably look at how expansion occurs for your tests on other
> ports that make heavy use of high/lo_sum.  sparc & hppa come immediately to
> mind, but I'm sure there's others.
>
> jeff
>

How to define PSImode for a target?

[Lev Yudalevich]

Hi,

While working on a port for my custom target I'm looking for some
advice on how to define a smaller-than-integer scalar mode.
I'd like to use it together with
__attribute__((__libgcc_cmp_return__)) mode attribute.
In my target xx-modes.def file I have PARTIAL_MODE_INT(SI) defined.
And my TARGET_LIBGCC_CMP_RETURN_MODE hook is set to a function
returning PSImode.
However, compilation of the libgcc fails in libgcc2.h at line 172 with
an error message: no data type for mode libgcc_cmp_return (the gcc
version I'm working on is 4.4.1).
PARTIAL_MODE_INT seems to be kind of undocumented feature. Can anybody
suggest the steps required to use it properly?

Sincerely,
-- Lev.

How to define target-specific PSImode?

[Lev Yudalevich]

Hi,

I asked this question about a month ago at gcc-help, but got no answer, so...

I'm trying to define a nonstandard type for 12-bit scalar variables
based on a target-dependent PSI mode.
In my TARGET-modes.def file I have PARTIAL_MODE_INT(SI) defined.
During the backend's init_builtins processing I do the following:
  tree t = make_unsigned_type (12);
  (*lang_hooks.types.register_builtin_type) (t, "mybit12_t");
  SET_TYPE_MODE (PSImode);
However, when the resulting gcc compiler crashes (ICE) when it tries
to convert any integer into my new type.

I would really appreciate any help on this problem and even general
guidance on how to properly define the PSI mode for scalar data (all
ports I'm aware of use the PSImode for pointers, and not scalars).
PARTIAL_MODE_INT seems to be kind of undocumented feature. Can anybody
suggest the steps required to use it properly?

(the gcc version I'm working on is 4.4.1).

Sincerely,
-- Lev.

Re: How to define target-specific PSImode?

[Lev Yudalevich]

Bug 42310 has been added to the database
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42310
Thank you very much!

Below is a copy of the bug report:

The exact version of GCC: 4.4.1

The system type: Linux version 2.6.9-67.EL (Red Hat 3.4.6-8)

The options given when GCC was configured/built: ../../gcc/configure
--target=testtarget --prefix=/usr/local/testtarget
--enable-target-optspace --enable-checking --disable-nls
--enable-languages=c,c++
Thread model: single

The complete command line that triggers the bug: testtarget-gcc -c loop.c

I'm trying to define a nonstandard type for 12-bit scalar variables
based on a target-dependent PSI mode.

In my backend's testtarget-modes.def I have:
  PARTIAL_INT_MODE (SI);

In my backend's testtarget_init_builtins() function
(TARGET_INIT_BUILTINS) I have the following:
  /* Create builtin type for 12-bit integer numbers (partial int) */
  tree t = make_unsigned_type (9);
  (*lang_hooks.types.register_builtin_type) (t, "mybit12_t");
  SET_TYPE_MODE (t, PSImode);

the compiler output:
testtarget-gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See  for instructions.

The resulting gcc compiler crashes (ICE) when it tries to convert any
integer into my new type.
I tried to debug it and what I see is that it goes back and forth
until the stack is exhausted between two functions: convert and
convert_to_integer:

#0  convert_to_integer (type=0xb7eb20d0, expr=0xb7e3caf0) at
../../../gcc/gcc/convert.c:389
#1  0x08079974 in convert (type=0xb7eb20d0, expr=0xb7e3caf0) at
../../../gcc/gcc/c-convert.c:101
#2  0x08080edc in convert_and_check (type=0xb7eb20d0, expr=0xb7e3caf0)
at ../../../gcc/gcc/c-common.c:1812
#3  0x08068c5c in convert_for_assignment (type=0xb7eb20d0,
rhs=0xb7e3caf0, errtype=ic_assign, fundecl=0x0, function=0x0,
parmnum=0) at ../../../gcc/gcc/c-typeck.c:4212
#4  0x080720b6 in build_modify_expr (location=1619, lhs=0xb7ec,
modifycode=NOP_EXPR, rhs=0xb7e3caf0) at
../../../gcc/gcc/c-typeck.c:3948
#5  0x080a984c in c_parser_expr_no_commas (parser=0xb7ebe0fc,
after=0x0) at ../../../gcc/gcc/c-parser.c:4421
#6  0x080a9914 in c_parser_expression (parser=0xb7e3caf0) at
../../../gcc/gcc/c-parser.c:5664
#7  0x080af9fd in c_parser_for_statement (parser=0xb7ebe0fc) at
../../../gcc/gcc/c-parser.c:4101
#8  0x080a63de in c_parser_statement_after_labels (parser=0xb7ebe0fc)
at ../../../gcc/gcc/c-parser.c:3700
#9  0x080a71b5 in c_parser_compound_statement_nostart
(parser=0xb7ebe0fc) at ../../../gcc/gcc/c-parser.c:3470
#10 0x080aec1b in c_parser_compound_statement (parser=0xb7ebe0fc) at
../../../gcc/gcc/c-parser.c:3318
#11 0x080af1e7 in c_parser_declaration_or_fndef (parser=0xb7ebe0fc,
fndef_ok=1 '\001', empty_ok=1 '\001', nested=0 '\0',
start_attr_ok=Variable "start_attr_ok" is not available.
) at ../../../gcc/gcc/c-parser.c:1307
#12 0x080b0e95 in c_parser_external_declaration (parser=0xb7ebe0fc) at
../../../gcc/gcc/c-parser.c:1076
#13 0x080b1c79 in c_parse_file () at ../../../gcc/gcc/c-parser.c:979
#14 0x0809af6c in c_common_parse_file (set_yydebug=0) at
../../../gcc/gcc/c-opts.c:1252
#15 0x0832a409 in toplev_main (argc=12, argv=0xbff91014) at
../../../gcc/gcc/toplev.c:970
#16 0x080bddb7 in main (argc=12, argv=0xbff91014) at ../../../gcc/gcc/main.c:35

The preprocessed file that triggers the bug:
int main (int argc, char *argv[]) {
  mybit12_t i;
  for (i = 0; i < 20; i++)
printf ("%d", i);
  return 0;
}

Re: How to define target-specific PSImode?

[Lev Yudalevich]

First, thank you very very much for your reply!
Next, would you be so kind to give me a hint where can I find any info
about what you called "required conversions patterns from / to
PSImode" please?

Sincerely,
-- Lev.

On Mon, Dec 7, 2009 at 6:10 AM, Joern Rennecke  wrote:
> Quoting Robert Dewar :
>
>> Lev Yudalevich wrote:
>>>
>>> However, when the resulting gcc compiler crashes (ICE) when it tries
>>> to convert any integer into my new type.
>>
>> Plase report the specific crash as a bug report with full details,
>> in particular a full compilable example that shows the ICE. Obviously
>> gcc should never crash, no matter whether your code is right or wrong.
>
> Actually, if the port uses PSImode, but lacks one of the required
> conversions
> patterns from / to PSImode, an an internal compiler error from a gcc_assert
> /
> gcc_unreachable would be expected.  Or, if the compiler is not configured
> for run-time checks, it might crash.
>

Re: How to define target-specific PSImode?

[Lev Yudalevich]

> Note that the m32c port uses PSImode, so it may offer some suggestions
> as example code.

Yes, that's right, but the m32c port uses it as a mode for pointers,
while I'm trying to do it with scalars.
Anyway, thank you very much.