llvm dev - May 2019 - Why did "llvm.memcpy" changed when emitting an object file?

Dear LLVM-Mailing list,

I have a beginners question again - please don't be mad at me!

I was playing around with llvm::Module instance and ended in iterating over all
global values and functions. I then noticed the function
"llvm.memcpy". As I understood, this is an intrinsic coming from the
LLVM.

So far so good! I then emitted an object file with the llvm::ExecutionEngine and
noticed an undefined references to "memcpy". Now I'm surprised! To
me, it looks like that the intrinsic turned into a 'normal' function. I
checked the iteration of the functions and were not able to locate any
"memcpy" there, this is why I'm assuming the intrinsic changed.

I wonder if this is true - I always thought that intrinsics will be replaced by
specific predefined assembly instructions, even the MSVC compiler provides a
memcpy intrinsic, so I don't understand why this function would appear, when
it was an intrinsic before. Did I maybe configured the EngineBuilder wrong? Or
the ExecutionEngine itself?

Kind greetings
Björn
Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr.
DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus
Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima. Junichi Tajika
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190509/b0995db3/attachment-0001.html>

On Thu, 9 May 2019 at 07:21, Gaier, Bjoern via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> So far so good! I then emitted an object file with the
llvm::ExecutionEngine and noticed an undefined references to "memcpy".
Now I'm surprised! To me, it looks like that the intrinsic turned into a
'normal' function.
That sounds very likely.
> I always thought that intrinsics will be replaced by specific predefined
assembly instructions, even the MSVC compiler provides a memcpy intrinsic, so I
don't understand why this function would appear, when it was an intrinsic
before.
LLVM assumes the runtime environment will provide basic string
functions (memcpy, and I think memset). Combine that with the fact
that @llvm.memcpy is more of a request to produce the best possible
memcpy rather than specifically to inline the sequence and we get the
behaviour you're seeing. LLVM will use an inline sequence if it thinks
that's going to be most efficient, otherwise it will call out to the
library one (typically when the number of bytes being copied is
unknown or large, and in -Oz mode).

Cheers.

Tim.

Hi Björn,

Your observation is correct, LLVM can "recreate" actual function calls
for intrinsics calls. 

Generally, there is no single way LLVM intrinsics are lowered. It
depends on the intrinsic and the target (afaik). Some, especially target
specific ones, are lowered to assembly sequences. Others, are simply
dropped or replaced by one of their arguments (some annotations).
Memory operations, among others, can be "lowered" to calls to library
calls, e.g., in IntrinsicLowering::LowerIntrinsicCall. Though, memcpy
can also be lowered to a sequence of load/stores in
SelectionDAG::getMemcpy() (via getMemcpyLoadsAndStores). I guess the
fact that you use the JIT interface might be a reason you see the former
lowering but I don't know for sure. 

I hope this general answer helps, otherwise you can probably get a more
detailed response from a backend person.

Cheers,
  Johannes


On 05/09, Gaier, Bjoern via llvm-dev wrote:
> Dear LLVM-Mailing list,
> 
> I have a beginners question again - please don't be mad at me!
> 
> I was playing around with llvm::Module instance and ended in iterating over
all global values and functions. I then noticed the function
"llvm.memcpy". As I understood, this is an intrinsic coming from the
LLVM.
> 
> So far so good! I then emitted an object file with the
llvm::ExecutionEngine and noticed an undefined references to "memcpy".
Now I'm surprised! To me, it looks like that the intrinsic turned into a
'normal' function. I checked the iteration of the functions and were not
able to locate any "memcpy" there, this is why I'm assuming the
intrinsic changed.
> 
> I wonder if this is true - I always thought that intrinsics will be
replaced by specific predefined assembly instructions, even the MSVC compiler
provides a memcpy intrinsic, so I don't understand why this function would
appear, when it was an intrinsic before. Did I maybe configured the
EngineBuilder wrong? Or the ExecutionEngine itself?
> 
> Kind greetings
> Björn
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert
Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima. Junichi
Tajika
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190509/9511c37e/attachment.sig>

Hello Johannes and Tim,

Thank you for your answers! They really helped me.

Can I influence if intrinsics are lowered or not?
I set llvm::EngineBuilder::setOptLevel to
"llvm::CodeGenOpt::Aggressive"

And I couldn't find any flag in llvm::TargetOptions that might effect this
behavior.

Kind greetings
Björn

-----Original Message-----
From: Doerfert, Johannes <jdoerfert at anl.gov>
Sent: Donnerstag, 9. Mai 2019 08:55
To: Gaier, Bjoern <Bjoern.Gaier at horiba.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Why did "llvm.memcpy" changed when emitting an
object file?

Hi Björn,

Your observation is correct, LLVM can "recreate" actual function calls
for intrinsics calls.

Generally, there is no single way LLVM intrinsics are lowered. It depends on the
intrinsic and the target (afaik). Some, especially target specific ones, are
lowered to assembly sequences. Others, are simply dropped or replaced by one of
their arguments (some annotations).
Memory operations, among others, can be "lowered" to calls to library
calls, e.g., in IntrinsicLowering::LowerIntrinsicCall. Though, memcpy can also
be lowered to a sequence of load/stores in
SelectionDAG::getMemcpy() (via getMemcpyLoadsAndStores). I guess the fact that
you use the JIT interface might be a reason you see the former lowering but I
don't know for sure.

I hope this general answer helps, otherwise you can probably get a more detailed
response from a backend person.

Cheers,
  Johannes


On 05/09, Gaier, Bjoern via llvm-dev wrote:
> Dear LLVM-Mailing list,
>
> I have a beginners question again - please don't be mad at me!
>
> I was playing around with llvm::Module instance and ended in iterating over
all global values and functions. I then noticed the function
"llvm.memcpy". As I understood, this is an intrinsic coming from the
LLVM.
>
> So far so good! I then emitted an object file with the
llvm::ExecutionEngine and noticed an undefined references to "memcpy".
Now I'm surprised! To me, it looks like that the intrinsic turned into a
'normal' function. I checked the iteration of the functions and were not
able to locate any "memcpy" there, this is why I'm assuming the
intrinsic changed.
>
> I wonder if this is true - I always thought that intrinsics will be
replaced by specific predefined assembly instructions, even the MSVC compiler
provides a memcpy intrinsic, so I don't understand why this function would
appear, when it was an intrinsic before. Did I maybe configured the
EngineBuilder wrong? Or the ExecutionEngine itself?
>
> Kind greetings
> Björn
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr.
> Robert Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi
> Fukushima. Junichi Tajika
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

--

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov
Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr.
DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus
Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima. Junichi Tajika