Displaying 3 results from an estimated 3 matches for "scscx".
2019 Aug 08
2
Suboptimal code generated by clang+llc in quite a common scenario (?)
I found a something that I quite not understand when compiling a common piece of code using the -Os flags.
I found it while testing my own backend but then I got deeper and found that at least the x86 is affected as well. This is the referred code:
char pp[3];
char *scscx = pp;
int tst( char i, char j, char k )
{
scscx[0] = i;
scscx[1] = j;
scscx[2] = k;
return 0;
}
The above gets compiled for the x86 architecture like this:
; Function Attrs: nofree norecurse nounwind optsize uwtable
define i32 @tst(i8 signext %i, i8 signext %j, i8 signext %k) local_unnam...
2019 Aug 08
3
Suboptimal code generated by clang+llc in quite a common scenario (?)
This might not be the workaround you want because it is only available in
C, but you can use restrict to allow such optimizations.
https://godbolt.org/z/2gQ26f
Alex
On Thu, Aug 8, 2019 at 11:50 AM Michael Kruse via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> char* scscx is an universal pointer and may point to anything,
> including itself. That is, scscx might point to itself:
>
> scscx = (char*)&scscx;
>
> such that
>
> scscx[0] = ...
>
> changes the address scscx point to. A pointer to (int*) in contrast is
> only allowed to poi...
2019 Aug 08
2
Suboptimal code generated by clang+llc in quite a common scenario (?)
Hi Tim and Alex
Thanks for your replies.
So just to make it clear for me: does this imply that there’s indeed no way on the current version to tell the compiler or Clang to optimize this?
Thanks,
Joan
> On 8 Aug 2019, at 18:30, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> On Thu, 8 Aug 2019 at 17:08, Alex Brachet-Mialot via llvm-dev
> <llvm-dev at