This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PING][PATCH] constrain one character optimization to one character stores (PR 90989)


Jeff (et al.), do you have any outstanding questions/concerns
about the patch?


On 6/27/19 4:30 PM, Jeff Law wrote:
On 6/27/19 12:40 PM, Richard Biener wrote:
On June 27, 2019 7:04:32 PM GMT+02:00, Jakub Jelinek <> wrote:
On Thu, Jun 27, 2019 at 10:58:25AM -0600, Martin Sebor wrote:
The LHS is unsigned short so handle_char_store would not be called
because of the check in the caller.  You would need something like:

   MEM <char[2]> [(char *)&x] = { 'a', 'b' };

This is invalid, because the rhs is non-empty CONSTRUCTOR that doesn't
VECTOR_TYPE - verify_gimple_assign_single has:
      if (TREE_CODE (rhs1_type) == VECTOR_TYPE)
      else if (CONSTRUCTOR_NELTS (rhs1) != 0)
          error ("non-vector %qs with elements", code_name);
          debug_generic_stmt (rhs1);
          return true;

  MEM <char[2]> [(char *)&x] = MEM <char[2]> [(char *)"ab"];
is valid.  Or = {} would be valid too, even for array stores.

And you can of course write GIMPLE unit tests for the pass using the GIMPLE FE.
Yea.  And this may ultimately be the way we should think about testing
this kind of stuff where GIMPLE might allow something that is impossible
to express in C or C++.

Realistically I don't think any of us can be expected to know the dusty
corners of every language.  But we ought to be able to reason about
what's valid gimple and write tests using the gimple front-end to verify
how a particular construct would be handled.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]