similar to: The value of padding when storing an aggregate into memory

Hello Alexander, > Interesting topic. Is any such optimization reachable from C? Yes, I think so - both PassBuilder and PassManagerBuilder add MemCpyOpt & IPSCCP in the default pass pipeline. Juneyoung On Wed, Aug 19, 2020 at 8:43 PM Alexander Cherepanov <ch3root at openwall.com> wrote: > On 19/08/2020 06.05, Juneyoung Lee via llvm-dev wrote: > > LangRef isn't clear

Hi, I believe some Neon code doesn't get invoked properly, because all PRESUME macros were set in my build. Probably not all optimized functions are called directly under iOS. Regards, Victor -----Original Message----- From: Jonathan Lennox Sent: Thursday, August 30, 2018 11:59 AM To: Victor Cherepanov Cc: opus at xiph.org Subject: Re: [opus] NEON detection under iOs On iOS, configure

Hi, Thank you for a great work. Opus codec works great under many platforms. I have found a small performance issue under iOS platform. If the macro OPUS_HAVE_RTCD is not set, then encoder doesn't use some _neon functions at low bitrates (up to 64k). If the macro is set, then the compiler hits the error at opus/celt/arm/armcpu.c:153 (a function for detection missed). Being compared to Android

Hello Fedor. Thank you for the information. I made a simple patch that exposes PassInstrumentationCallback so llvmGetPassPluginInfo can use it: https://reviews.llvm.org/D71086 . Would this change make sense? Thanks, Juneyoung Lee On Thu, Dec 12, 2019 at 12:44 AM Fedor Sergeev <fedor.sergeev at azul.com> wrote: > > > On 12/3/19 8:01 PM, Juneyoung Lee via llvm-dev wrote: > >

I think it’s reasonable to expect that IR generated by frontends doesn’t do this. Not sure about transforms; I can imagine that we might speculate a load without proving all the bits are well-defined. -Eli From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Juneyoung Lee via llvm-dev Sent: Sunday, September 20, 2020 3:54 PM To: llvm-dev <llvm-dev at lists.llvm.org>

> > Okay, it's just not immediately undefined behaviour. The C model has more > issues because of the problem with how "trap representation" is defined > (which precludes trap representations for unsigned char, two's complement > signed char, etc.). This interpretation is further stressed because C only explicitly ascribes > undefined behaviour to trap

Hello all, Is it valid to dereference a pointer that has undef bits in its offset? For example, %p = alloca [8 x i8] %p2 = gep %p, (undef & 8) store 0, %p2 undef & 8 is always less than 8, so technically it will store zero to one of the array's elements. The reason is that I want to improve no-undef analysis by suggesting that a pointer that is passed to load/store is

I build new version of talloc-2.1.6 (build from external tarball) and samba-4.3.6. But if I provision domain by command samba-tool domain provision --realm=test.alt --domain test --adminpass='Pa$$word' --dns-backend=SAMBA_INTERNAL --server-role=dc --use-rfc2307 --use-xattrs=yes I got error: Fixing provision GUIDs ERROR(runtime): uncaught exception - pytalloc_reference_ex() called for

Thank you for the infos; it seems making it raise UB is problematic. Would clarifying it in LangRef be good? I can update the patch to contain the information instead. Another concern is then, how can we efficiently encode an assumption that a pointer variable in IR does not have undef bits? Certainly, in the front-end language, (most of) pointers won't have undef bits, and it would be great

> > // Members are initialized to poison at object creation. >> p = alloca {i8, i32} // p[0], p[4~7] are poison >> p[0] is an i8, so it shouldn't be poison? > > My interpretation of standard is that reading uninitialized char can also yield trap representation. If uninitialized, char variable has indeterminate value, and C/C++ does not seem to forbid reading trap

I think we need to allow this.  Otherwise, we have to prove that addresses are non-undef before we can hoist or sink a memory instruction.  Today, aliasing can use things like known bits, and if we imposed a no-undef in address requirement, we'd either need to replace such reasoning in AA, or have passes which wish to hoist/sink check the property afterwards. Or to say it differently, I

Hello all, How can I see the result of lazy value info analysis? I ran a command `opt -lazy-value-info -correlated-propagation -print-lazy-value-info example.ll -disable-output` with a following program as the input: ``` define i32 @f(i32 %a, i32 %b) { %i = icmp eq i32 %a, 10 br i1 %i, label %A, label %B A: %c = add i32 %a, 20 ret i32 %c B: ret i32 0 } ``` However, it shows a

It is UB when a poison is passed to certain operations that raise UB on poison, such as division by poison/dereferencing poison pointer/branching on poison condition/etc. Otherwise, poison is simply propagated, but it does not raise UB Copying poison bytes is okay: // Members are initialized to poison at object creation. p = alloca {i8, i32} // p[0], p[4~7] are poison q = alloca {i8, i32} // we

Hello Sanjoy, Yep, combining it with propagateEquality of pointers may raise problem. :\ However I believe propagateEquality should be fixed properly, and adding psub also suggests a solution for that. :) It is sound to replace a pointer with another if subtraction of them is 0: a = malloc() free(a) b = malloc() // Assume b == a numerically if ((psub inbounds a b) == 0) { // a and b are

Hello all, Is there a way to register callback that runs before/after passes? PassTimingInfo seems to do a similar thing by calling PassInstrumentationCallbacks::registerBeforePassCallback / registerAfterPassCallback, but it is hard-wired with StandardInstrumentations class. Do we have something similar to RegisterStandardPasses, so custom callbacks can be added from somewhere outside LLVM?

On 2016-05-20 19:58, David Majnemer via llvm-dev wrote: > I've come across this issue before and came to the following conclusion: > - We are not obligated to support objects that large, C11 5.2.4.1/1 only > requires that we support objects of size 65535! Right, the standard doesn't require it. But I guess you don't imply that it's fine for clang to silently miscompile

Two thoughts: 1. I think that we should aim for regularity, to the extent possible, and so we should treat nonnull, align, etc. similarly w.r.t. to whether they produce poison or UB. 2. I was thinking about the following last night, and it clarified for me why having an not_poison attribute makes sense and seems useful, and how poison/UB might affect things on a function-call boundary itself.

It seems MemorySSA.cpp is the only real code where we found the problem happening. Is it possible to change the source of MemorySSA.cpp to hide the problem and buy some time for now? Now we use an empty generic_def_path_iterator with Optional<ListIndex> N being initialized by None as the end of range. Can we initialize the Optional var with a special value instead of None?

Hello, some of the patches had conflicts with LLVM head, so I updated them. If you experienced patch failure before then you can try it again. I compiled your code (1.c) with LLVM r308173 with the 5 patches applied, and it generated assembly like this. Now it contains store to c(%rip). It tries to store a(%rip) + b(%rip) to c(%rip). I wish this translation is now correct. ``` 73 .globl hoo

> It is important to note that this applies to trap representations and not to unspecified values. A structure or union never has a trap representation. Yes, nondeterministic bits would work for padding of struct/union, as described in (3) The third case is the value of struct/union padding. For the members of struct/union, it is allowed to have trap representation, so poison can be used.