search for: matdzb

...he memory objects the addresses stored in the pointers refer to, i.e., i32** vs. i32* or i8*). Best, Matt > > Sorry for the potential trouble this may have caused.. And thank you > in advance! > > Best, > Shuai > > On Thu, Jul 9, 2020 at 9:58 PM Matt P. Dziubinski <matdzb at gmail.com > <mailto:matdzb at gmail.com>> wrote: > > Hi again! > > Replying in chronological order: > > > On Thu, Jul 9, 2020 at 6:51 PM Shuai Wang <wangshuai901 at gmail.com > <mailto:wangshuai901 at gmail.com> > > &lt...

On 7/13/2020 21:30, Thomas Lively via llvm-dev wrote: > Part of the problem is that ISel patterns are like their own DSL inside > the TableGen DSL, so keywords like "ins", "outs", and "ops" aren't > keywords at the TableGen level, but rather at the level of the ISel > system implemented with TableGen. Copying existing patterns and reading > the

On 9/29/2020 14:37, David Chisnall via llvm-dev wrote: > On 28/09/2020 15:45, Matt P. Dziubinski via llvm-dev wrote: >> Hey, I noticed this talk from the EuroLLVM 2015 >> (https://llvm.org/devmtg/2015-04/slides/pslp_slides_EUROLLVM2015.pdf) >> on the PSLP vectorization algorithm (CGO 2015 paper: >> http://vporpo.me/papers/pslp_cgo2015.pdf). >> >> Is anyone

Hi again! Replying in chronological order: > On Thu, Jul 9, 2020 at 6:51 PM Shuai Wang <wangshuai901 at gmail.com > <mailto:wangshuai901 at gmail.com>> wrote: > > Hey Matt, > > That's awesome. Thank you very much for all the information and > clarification! Just a few follow up questions. Could you kindly shed > some lights on it? Thank

...matched to instruction-to-be-generated? --help doesn't seem to indicate anything like that. On Tue, Jul 14, 2020 at 2:13 PM Rotate Right <rightrotate5 at gmail.com> wrote: > Thanks Matt and Thomas. I will go through them. > > On Tue, Jul 14, 2020, 1:35 PM Matt P. Dziubinski <matdzb at gmail.com> wrote: > >> On 7/13/2020 21:30, Thomas Lively via llvm-dev wrote: >> > Part of the problem is that ISel patterns are like their own DSL inside >> > the TableGen DSL, so keywords like "ins", "outs", and "ops" aren't >&g...

...y local opt (version 6.0). For opt (version 6.0), it reports: 2 alias sets for 2 pointer values. More importantly, can I expect to get generally better alias analysis results when switching to version 11.0? Thank you very much! Best, Shuai On Thu, Jul 9, 2020 at 6:14 PM Matt P. Dziubinski <matdzb at gmail.com> wrote: > On 7/9/2020 10:15, Shuai Wang via llvm-dev wrote: > > Hello, > > > > I am performing alias analysis toward the following simple code: > > > > [...] > > > > I checked the generated .ll code, and it shows that within the main &gt...

Hi, Not sure whether this matches your use case, but the Orc-based JIT used in LLI appears to be using `llvm::orc::LocalCXXRuntimeOverrides` (http://llvm.org/doxygen/classllvm_1_1orc_1_1LocalCXXRuntimeOverrides.html) to override `__cxa_atexit`: https://github.com/llvm-mirror/llvm/blob/release_50/tools/lli/OrcLazyJIT.h#L74

Hello, I am performing alias analysis toward the following simple code: struct MyStruct { int * f1; int * f2; }; void NOALIAS(void* p, void* q){ } int main() { struct MyStruct s[2]; int a,b; s[0].f1 = &a; s[1].f1 = &b; NOALIAS(s[a].f1, s[b].f2); return 0; } When I use the following command to generate .bc code and conduct alias analysis: clang -c -emit-llvm t.c -O2 opt -basicaa

Maybe the easiest workaround would be overriding symbol resolution for the function name and redirect it to your own version in static code (and hope it has no bad side effect on your use case). I think when running 3rd party code, the only way to definitely avoid this kind of trouble is to never deallocate any code or data sections. Doug Binks mentioned that too in his cppcast about Runtime