On Thu, 31 Aug 2006, Kamesh Jayachandran wrote:
> Daniel Berlin wrote:
> >>>
> >>I am not sure about the speed.
> >>I thought copying 8 bytes at one shot should be faster than dereferncing
> >>4 integer items and assigning them.
> >
> >Again, the compiler will turn one into the other depending on a number
> >of factors, including register pressure, etc.
> >
> >>If I understand this segment of code it just takes the 'forward merge
> >>ranges', which this '*(*output) = *in1; ' should be more meaningful with
> >>the associated commit message.
> >
> >At least to me, it's less meaningful to do structure copies in a lot
> >of cases.
> >Others may disagree.
> >
> Barring the (confusing???)structure copy stuff, the code segment
> essentially assigns 'in1' or 'in2' to output.
> Initially seeing a function having 6 else if blocks doing some checks
> with 'in1' and 'in2's members and extracting the same and assigning to
> some other structure, I felt bit difficult to differentiate this
> particular 'else if' blocks with others on the first glance. After all
> mental imaging of 'in1' and 'in2', I found that 'foo... this is just
> avoiding revert the range'
In this case, I find the structure copy style very slightly more
comprehensible.
> Anyways..........
> What is our stance on 'revert range' combining.
IIRC, we don't support it, which explains the (undefined) behavior you
describe below.
> Currently 'combine_ranges' for in1(5,9) in2(10, 6) sets *output to
> (5,9), is it correct? I feel we should return FALSE without changing the
> '*output' like we do for (5, 9) and (17, 26).
- application/pgp-signature attachment: stored
Received on Sat Sep 2 00:52:09 2006