search for: hopefolly

...n undefined behaviour, and would need to be > documented in the LangRef. It already is: "Overestimating the alignment results in an undefined behavior." (both load and store). But implementing this kind of optimization is not that easy, since it would require to 1) visit other uses (hopefolly an aligned load/store) of the pointer for which we want to know the Known-Zero-Bits, and 2) know the dominance tree, since exploiting the knowledge about the alignment of the pointer is only valid after the load/store has been executed. As far as I can see, both is not done in InstCombine yet,...

...d need to be >> documented in the LangRef. > > It already is: "Overestimating the alignment results in an undefined behavior." > (both load and store). > But implementing this kind of optimization is not that easy, since it would > require to > 1) visit other uses (hopefolly an aligned load/store) of the pointer for which > we want to know the Known-Zero-Bits, and > 2) know the dominance tree, since exploiting the knowledge about the alignment > of the pointer is only valid after the load/store has been executed. > > As far as I can see, both is not done...

Hi Clemens, > I'm instrumenting IR by replacing loads and stores by calls to a library, which > I have compiled to bitcode such that inlining can take place. My problem is: If > I could retain the alignment information on the load/store, this would open many > optimization opportunities after inlining. Unfortunately, I don't know how. > > After thinking about it, and

Hi all, I'm instrumenting IR by replacing loads and stores by calls to a library, which I have compiled to bitcode such that inlining can take place. My problem is: If I could retain the alignment information on the load/store, this would open many optimization opportunities after inlining. Unfortunately, I don't know how. After thinking about it, and trying different things, I now