thr3ads.net - llvm dev - [llvm-dev] Preserving Call to Intrinsic function [Jan 2017]

If this information is useful, please help other people find it:
Share via:

Kumail Ahmed via llvm-dev

2017-Jan-27 16:33 UTC

[llvm-dev] Preserving Call to Intrinsic function

Hello everyone,


Consider we have this following set of code:

int foo() {

int a,b;
a = __builtin_XX(0x11);
b = __builtin_XX(0x11);
return a+b;
}

The problem currently is that LLVM eliminated the second call and copied
the result from the first call into a new set of registers. Is there is a
way to force LLVM to generate two explicit calls to a builtin function. The
builtin takes in an integer type, and also returns back an integer type:

  def int_XX : GCCBuiltin<"__builtin_XX">,
Intrinsic<[llvm_i32_ty],
[llvm_i32_ty]>;

Is there some flag that I'm missing? Your help will be really appreciated.


Best Regards,
Kumail Ahmed
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170127/4335399b/attachment.html>

Pierre-Andre Saulais via llvm-dev

2017-Jan-27 17:05 UTC

head link

[llvm-dev] Preserving Call to Intrinsic function

Hi Kumail,

There is a flag that does what you are looking for (see Intrinsics.td
for definitions):

// IntrNoduplicate - Calls to this intrinsic cannot be duplicated.
// Parallels the noduplicate attribute on LLVM IR functions.
def IntrNoDuplicate : IntrinsicProperty;

Another thing to check is whether your intrinsic is marked as having
side-effects or not. Intrinsics with no side effects may be optimized by
LLVM. If you inspect the DAG using llc, an intrinsic with side-effects
should have a chain (blue dashed edge) going to and coming from its node:

llc -O1 foo.ll -view-isel-dags

If it doesn't, you can mark it as having side-effects using one of the
following attributes:

// IntrReadMem - This intrinsic only reads from memory. It does not write to
// memory and has no other side effects. Therefore, it cannot be moved
across
// potentially aliasing stores. However, it can be reordered otherwise
and can
// be deleted if dead.
def IntrReadMem : IntrinsicProperty;

// IntrWriteMem - This intrinsic only writes to memory, but does not
read from
// memory, and has no other side effects. This means dead stores before
calls
// to this intrinsics may be removed.
def IntrWriteMem : IntrinsicProperty;

By default intrinsics returning void are assumed to have side effects.

Pierre-Andre

On 27/01/17 16:33, Kumail Ahmed via llvm-dev wrote:> Hello everyone,
>
>
> Consider we have this following set of code:
>
> int foo() {
>
> int a,b;
> a = __builtin_XX(0x11);
> b = __builtin_XX(0x11);
> return a+b;
> }
>
> The problem currently is that LLVM eliminated the second call and
> copied the result from the first call into a new set of registers. Is
> there is a way to force LLVM to generate two explicit calls to a
> builtin function. The builtin takes in an integer type, and also
> returns back an integer type:
>
>   def int_XX : GCCBuiltin<"__builtin_XX">,
Intrinsic<[llvm_i32_ty],
> [llvm_i32_ty]>;
>
> Is there some flag that I'm missing? Your help will be really
appreciated.
>
>
> Best Regards,
> Kumail Ahmed
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Pierre-Andre Saulais
Principal Software Engineer, Compilers
Codeplay Software Ltd
Level C Argyle House, 3 Lady Lawson Street, Edinburgh, United Kingdom, EH3 9DR
Tel: +44 (0)131 466 0503
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft

This email and any attachments may contain confidential and /or privileged
information and is for use by the addressee only. If you are not the intended
recipient, please notify Codeplay Software Ltd immediately and delete the
message from your computer. You may not copy or forward it, or use or disclose
its contents to any other person. Any views or other information in this message
which do not relate to our business are not authorized by Codeplay software Ltd,
nor does this message form part of any contract unless so stated.
As internet communications are capable of data corruption Codeplay Software Ltd
does not accept any responsibility for any changes made to this message after it
was sent. Please note that Codeplay Software Ltd does not accept any liability
or responsibility for viruses and it is your responsibility to scan any
attachments.
Company registered in England and Wales, number: 04567874
Registered office: Regent House, 316 Beulah Hill, London, United Kingdom, SE19
3HF

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170127/3ad06e64/attachment.html>

Kumail Ahmed via llvm-dev

2017-Jan-27 17:50 UTC

head link

[llvm-dev] Preserving Call to Intrinsic function

Hi Pierre,

Thank you for your swift response!

I've tried almost everything that you mentioned, but it seems like LLVM
simply doesn't care about the flags I pass to it.

Best regards,
Kumail Ahmed

On Fri, Jan 27, 2017 at 6:05 PM, Pierre-Andre Saulais <
pierre-andre at codeplay.com> wrote:
> Hi Kumail,
>
> There is a flag that does what you are looking for (see Intrinsics.td for
> definitions):
>
> // IntrNoduplicate - Calls to this intrinsic cannot be duplicated.
> // Parallels the noduplicate attribute on LLVM IR functions.
> def IntrNoDuplicate : IntrinsicProperty;
>
> Another thing to check is whether your intrinsic is marked as having
> side-effects or not. Intrinsics with no side effects may be optimized by
> LLVM. If you inspect the DAG using llc, an intrinsic with side-effects
> should have a chain (blue dashed edge) going to and coming from its node:
>
> llc -O1 foo.ll -view-isel-dags
>
> If it doesn't, you can mark it as having side-effects using one of the
> following attributes:
>
> // IntrReadMem - This intrinsic only reads from memory. It does not write
> to
> // memory and has no other side effects. Therefore, it cannot be moved
> across
> // potentially aliasing stores. However, it can be reordered otherwise and
> can
> // be deleted if dead.
> def IntrReadMem : IntrinsicProperty;
>
> // IntrWriteMem - This intrinsic only writes to memory, but does not read
> from
> // memory, and has no other side effects. This means dead stores before
> calls
> // to this intrinsics may be removed.
> def IntrWriteMem : IntrinsicProperty;
> By default intrinsics returning void are assumed to have side effects.
>
> Pierre-Andre
>
>
> On 27/01/17 16:33, Kumail Ahmed via llvm-dev wrote:
>
> Hello everyone,
>
>
> Consider we have this following set of code:
>
> int foo() {
>
> int a,b;
> a = __builtin_XX(0x11);
> b = __builtin_XX(0x11);
> return a+b;
> }
>
> The problem currently is that LLVM eliminated the second call and copied
> the result from the first call into a new set of registers. Is there is a
> way to force LLVM to generate two explicit calls to a builtin function. The
> builtin takes in an integer type, and also returns back an integer type:
>
>   def int_XX : GCCBuiltin<"__builtin_XX">,
Intrinsic<[llvm_i32_ty],
> [llvm_i32_ty]>;
>
> Is there some flag that I'm missing? Your help will be really
appreciated.
>
>
> Best Regards,
> Kumail Ahmed
>
>
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at
lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> --
> Pierre-Andre Saulais
> Principal Software Engineer, Compilers
> Codeplay Software Ltd
> Level C Argyle House, 3 Lady Lawson Street, Edinburgh, United Kingdom, EH3
9DR
> Tel: +44 (0)131 466 0503 <+44%20131%20466%200503>
> Website: http://www.codeplay.com
> Twitter: https://twitter.com/codeplaysoft
>
> This email and any attachments may contain confidential and /or privileged
information and is for use by the addressee only. If you are not the intended
recipient, please notify Codeplay Software Ltd immediately and delete the
message from your computer. You may not copy or forward it, or use or disclose
its contents to any other person. Any views or other information in this message
which do not relate to our business are not authorized by Codeplay software Ltd,
nor does this message form part of any contract unless so stated.
> As internet communications are capable of data corruption Codeplay Software
Ltd does not accept any responsibility for any changes made to this message
after it was sent. Please note that Codeplay Software Ltd does not accept any
liability or responsibility for viruses and it is your responsibility to scan
any attachments.
> Company registered in England and Wales, number: 04567874
<04567%20874>
> Registered office: Regent House, 316 Beulah Hill, London, United Kingdom,
SE19 3HF
>
>

-- 
Best Regards,
Kumail Ahmed
M.Sc. Student
TU Kaiserslautern
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170127/e4e0aac3/attachment.html>

llvm dev - Jan 2017 - Preserving Call to Intrinsic function

[llvm-dev] Preserving Call to Intrinsic function

[llvm-dev] Preserving Call to Intrinsic function

[llvm-dev] Preserving Call to Intrinsic function