Missing case of compile-time constant folding

[tschwinge]

The example code https://godbolt.org/z/8o74c57Yj (via https://lkml.org/lkml/2021/7/4/171, via https://gcc-rust.zulipchat.com/#narrow/stream/266897-general/topic/Rust.20for.20Linux.20RFC.3A.20Another.20mention.20of.20GCC-RS) shows a missing case of compile-time constant folding.

At this time, we produce (see gccrs-snapshot tab):

TestCrate::S::sum:
        lea     rax, [rdi+rsi]
        ret
TestCrate::f:
        mov     edi, 123
        mov     esi, 42
        jmp     TestCrate::S::sum

..., whereas rustc 1.53.0 produces:

example::f:
        mov     eax, 165
        ret

[tschwinge]

(Note that I haven't checked what generally we're doing with respect to compile-time constant folding.)

[philberty]

I think the bug isn't necessarily to do with constant folding in the front-end. I think it is because of the missing: #241

Currently when we define a method with &self the reference part of the type is currently ignored since we need to support #434 as part of that in the type system. Its something I was going to be working on this month. I was able to verify this by testing a similar c++ piece of code that GCC will optimize this but from that example in rust our gimple dump shows:

usize S_sum (const struct  self)
{
  usize D.206;

  _1 = self.0;
  _2 = self.1;
  D.206 = _1 + _2;
  return D.206;
}


usize f ()
{
  usize D.208;
  struct  D.209;

  D.209.0 = 123;
  D.209.1 = 42;
  D.208 = S_sum (D.209);
  return D.208;
}

[bjorn3]

Unlike LLVM, GCC doesn't assume -fno-semantic-interposition, so it is valid to replace TestCrate::S::sum with a different function if it is exported. Specifying -fno-semantic-interposition doesn't seem to help though, though it should probably be the default at least for non-#[no_mangle] symbols. By the way when checking "compile to binary" I see several __morestack calls that complicate the disassembly a lot.

[philberty]

Also it looks like there might be another bug since its referencing usize here not u64

[philberty]

Found the bug with the gimple reference to 'usize' it was a bad call to named_type to give the integer type a relevant name in gimple land. The underlying integer type was correct but the name was bad.

[philberty]

Found the issue is here: https://github.com/Rust-GCC/gccrs/blob/master/gcc/rust/rust-gcc.cc#L3373-L3374

We need to explicitly set function_is_inlinable flags other wise the rust-gcc.cc wrapper ensures that this function is un-inlinable. I think it makes sense being able to turn this on and off, so lets make the flags default allow for inlining