rust slice.as_ptr() should use getelementptr, not bitcast/load

[taralx]

bytes!(...).as_ptr() is used in freestanding code to produce needed byte arrays with specific content. This causes an entire allocation of the slice data in rustc:

@const = private constant [6 x i8] c"TEXT!\00"
@_ZN4main5BYTES20h0c254b3a0ff92eb8Naa4v0.0E = internal unnamed_addr constant { i8*, i32 } { i8* getelementptr inbounds ([6 x i8]* @const, i32 0, i32 0), i32 6 }

whereas in clang, the structure is elided, as evidenced by compiling this C code with -O4 -S:

static struct {
  char *ptr;
  int size;
} ZN = {"TEXT!", 6};

int main() {
  return (int) ZN.ptr;
}

[thestinger]

The specific Rust code you're comparing with is missing.

[huonw]

This causes an entire allocation

What do you mean by this? (There is no allocation occuring.)

In any case, I tried it myself:

#[start]
fn main(_: int, _: **u8) -> int {
    (bytes!("TEXT!").as_ptr()) as int
}

which compiles to the following with -O:

; ModuleID = '14761.rs'
target datalayout = "e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

@const = private constant [5 x i8] c"TEXT!"

; Function Attrs: nounwind readnone
define i64 @main(i64, i8** nocapture readnone) unnamed_addr #0 {
top:
  ret i64 ptrtoint ([5 x i8]* @const to i64)
}

attributes #0 = { nounwind readnone "split-stack" }

You C code gives:

; ModuleID = '14761.c'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"

@.str = private unnamed_addr constant [6 x i8] c"TEXT!\00", align 1

; Function Attrs: nounwind readnone uwtable
define i32 @main() #0 {
  ret i32 ptrtoint ([6 x i8]* @.str to i32)
}

attributes #0 = { nounwind readnone uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="false" "no-frame-pointer-elim-non-leaf"="false" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "unsafe-fp-math"="false" "use-soft-float"="false" }

[taralx]

Okay, I'm still trying to track this down. It's apparently linked to which specific triple I'm using -- sometimes the right thing happens, and sometimes a bunch of ugly pointer math appears that breaks llvm's optimization phase. I'll update the main part of this when I understand what's going on.

[taralx]

Strike that -- I'll open a new issue when I understand what's going on.