Added a check that an instruction is inlined before to try to find inlined CUs.

Reduce code duplication.

I'm closing this review as current patch is not fixing the issue properly.

When reading the following definition of method 'MaybeAlign Value::getPointerAlignment(const DataLayout &DL) const' most users assume that Value won't be modified by this method. If we don't guarantee it then it would be nice to remove const-qualifier and change name on something like 'accountPointerAlignment'. As renaming is less possible then a comment might be present that this method may change an IR.

In D74700#1878635, @lebedev.ri wrote:

I don't believe the question

In D73131#1865811, @nikic wrote:

Sounds pretty odd to me too. From a quick grep, there's only a handful of destroyConstant() uses outside GlobalOpt, and those tend to deal with BlockAddress only (which is somewhat particular about uses).

was answered. Do we have this guarantee in the first place?

In D73131#1861595, @mlychkov wrote:

...
Is this alignment accounting intended to be used for getelementptr instructions too?
If yes then may we cleanup extra user after we get TrailingZeros value?

Hi @lebedev.ri,
We faced some side effect of this patch. During processing of getelementptr instruction it may create new user of this instruction. However this user is not actually used by generated code.
As example, during processing of the following instruction

%3 = load %struct_t*, %struct_t** getelementptr inbounds ([8 x %struct_t*], [8 x %struct_t*]* @globvar, i64 0, i64 0), align 8, !tbaa !16

the following constant expresion is created